GNOME Bugzilla – Bug 518128
Fixed decimal number subtraction doesn't give 0 (Zero)
Last modified: 2008-02-23 14:27:08 UTC
Please describe the problem: I need to subtract from a positive integer number several positive fixed numbers (integer or decimal) since it reaches 0. Almost all subtraction went fine except one, which didn't give 0 (zero) as result. I'm using win32 version 1.7.12. Steps to reproduce: 1. A1=65;B1=19,66;C1=12,33;D1=16,49;E1=16,52; 2. F1=A1-B1-C1-D1-E1; Actual results: Cell F1 is something like 7,105E-105. Expected results: Cell F1 should have been 0 (zero). Does this happen every time? Yes. Other information:
Some of the numbers you have cannot be exactly represented in IEEE floating point standard. So your difference is in fact not 0. *** This bug has been marked as a duplicate of 509965 ***
The problem is how you (In reply to comment #1) > Some of the numbers you have cannot be exactly represented in IEEE floating > point standard. So your difference is in fact not 0. > > *** This bug has been marked as a duplicate of 509965 *** > Well, i tought it depended on it. I tried converting the fields from generic to another format: 1. Numeric: result 0; 2. Currency : result 0 (i hope currency translates correctly valuta in italian); 3. Contability: result 0 (in Contability A1=x;B1=x, where x=any value, C1=A1-B1=-0 and not 0); 4. Scientific: result something like 7,105E-15; So the problem of the representation has been somehow addressed in the first 3 cases and not in the others. Since the fields are created generic by default, a misbehaviour like this one would make non-technician people think this software is not reliable. I hope to be of any help.
Formatting a cell changes what is displayed, not the underlying value. Read comment number 4 in bug 509965 for why this is a representation problem inherent with base 2 arithmetic. Ending up near zero just makes the problem more visible. *** This bug has been marked as a duplicate of 509965 ***