https://issues.apache.org/ooo/show_bug.cgi?id=117841
orcmid <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |RESOLVED CC| |[email protected] Resolution|--- |INVALID --- Comment #7 from orcmid <[email protected]> --- This is not a defect. 0.1, 1.2, and 3.3 are not carried as exact values. They are approximated by very close values within the precision of the floating-point numbers that are used. It is not unusual for differences that should be exact integers (including 0) to have very small errors. This is by design. (The form of arithmetic used can only represent fractional numbers as integers divided by integer powers of 2. It's the same problem that there is in representing 1/3 in decimal, only now 1/10, 2/10, and 3/10 also require approximations in the computer arithmetic.) This is usually handled by rounding the final result to the desired meaningful precision and/or specifying a cell format that has the small errors be ignored. Another option is to use Tools | Options | Calc | Calculate and check "Limit decimals for general number format" and set a number of decimal places to a reasonable number, such as 6. The result cell, E2, will then show 0. The internal value will *still* have a small error, and you can see it if you change the cell Number format to Scientific. This is consistent behavior. The result is confirmed in Apache OpenOffice 3.4.1, LibreOffice 3.3.2, Microsoft Excel 2013 (Preview), and LibreOffice 3.6.4. -- You are receiving this mail because: You are on the CC list for the bug.
