GNOME Bugzilla – Bug 613557
Rounding error on 103.47+404.32
Last modified: 2011-10-28 16:33:46 UTC
I stumbled upon this bug in Linux Gnumeric 1.8.2 and reproduced it in Windows Gnumeric 1.9.1. I don't have a more recent version to hand to try. It's easy to reproduce. Simply type "=103.47+404.32-507.79" into a cell. It should give "0" (as in Excel and OpenOffice) but I get -5.6843418860808E-14 instead. I get the same problem using SUM. This problem is evident with other numbers too, so it is more generic than my specific example. Could someone test it in 1.10.1 to see if it has been resolved by other bug fixes? Thanks.
Why should it give 0? None of those three numbers is exactly representable in a computer, so instead of the three numbers three approximation are used. It would be quite surprising if those three approximations would happen to cancel. (OOo and Excel assumes that you probably don't wnat exact calculations and so show you zero. Of course you typically don't want that if you are really interested in correct calculations. We get this comment regularly and so there is an open report about that. THis report should be marked a duplicate of that one.
*** This bug has been marked as a duplicate of bug 509965 ***
(In reply to comment #1) > Why should it give 0? None of those three numbers is exactly representable in a > computer, so instead of the three numbers three approximation are used. It > would be quite surprising if those three approximations would happen to cancel. > (OOo and Excel assumes that you probably don't wnat exact calculations and so > show you zero. Of course you typically don't want that if you are really > interested in correct calculations. > > We get this comment regularly and so there is an open report about that. THis > report should be marked a duplicate of that one. It should give 0 because 0 is the correct answer. The computer's internal representation is not "exact" as you put it, but merely accurate up to a certain number of decimal places (or perhaps significant figures). However this computer generated error is meaningless to almost all human purposes. Why retain predictable computer inaccuracies in the resulting computation? Is there a real life situation where this is a benefit? I've posted a reply to the original bug 509965. Apologies for not spotting that I was creating a duplicate - I didn't realise that they were related until it was pointed out. Thanks for your really great spreadsheet application - I love it!
We disagree. We also know that Excel and OpenOffice adjust their numbers to match what some users expect.
*** Bug 662938 has been marked as a duplicate of this bug. ***