Bug 94967

Summary: EDITING SUM() infinitesimal results instead of 0
Product: LibreOffice Reporter: Robert Gonzalez MX <ggrc670>
Component: CalcAssignee: Not Assigned <libreoffice-bugs>
Status: RESOLVED NOTABUG    
Severity: normal CC: ggrc670, jmadero.dev
Priority: medium    
Version: 5.0.1.2 release   
Hardware: Other   
OS: All   
Whiteboard:
Crash report or crash signature: Regression By:
Attachments: Calc test file with examples and testings

Description Robert Gonzalez MX 2015-10-11 22:22:34 UTC
Hello.
I found this problem in the SUM() function.

Description:
When using the SUM() function to a range of negative and positive numbers in a column, with general formatting or Format -Number- standard, the result that should be 0, is a negative or positive number with exponential notation Like 2.8421709430404E-14.

The numbers used are natural numbers with two decimal digits.


Steps to reproduce
Create a spreadsheet and make a list of numbers like this
5.66
-5.66
10.81
20.3
2.54
4.56
9.87
165.25
-9.87
-165.25
-20.3
-2.54
-10.81
-4.56
in the end, the sum of all this numbers is 0

Use the SUM() function 
calc's result is -2.1316282072803E-14

copy transposed and the result in horizontal mode is the same.

If the formatting is used, the correct result ( 0 ) is displayed, but if the numbers are used in to a pivot table, the result is -0.00 but the real number is something like 0.000000000000028421709430404

When selecting the list of numbers and with shift down arrow, and setting the status bar to sum, you can see that as you advance in the selection, the result is a negative or positive number or 0 at some point, but when reaching the last element, the result in the status bar is also an infinitesimal value with exponential notation.

Tested with LO 4.4.5.2, 5.0.1.2, 5.0.2.2, 5.1.0.0 alpha1+ on windows 10

I'm submitting a test file.
Comment 1 Robert Gonzalez MX 2015-10-11 22:23:59 UTC
Created attachment 119524 [details]
Calc test file with examples and testings
Comment 2 Joel Madero 2015-10-11 22:43:13 UTC
This is not a bug but instead just a result of computational errors that are unavoidable with floating numbers. This has been explained a number of times by some of our top developers. You can google "rounding errors with floating point numbers" and you will see a number of relevant hits that explains why it happens. Closing as NOTABUG