https://bugs.documentfoundation.org/show_bug.cgi?id=157856

Mike Kaganski <mikekagan...@hotmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |NOTABUG
           See Also|                            |https://bugs.documentfounda
                   |                            |tion.org/show_bug.cgi?id=13
                   |                            |0725

--- Comment #6 from Mike Kaganski <mikekagan...@hotmail.com> ---
Ah fun!
This is not a bug at all. In fact, this now works correctly, and it didn't
before. Specifically, this change of behavior happened in v.7.0, as the result
of fixing bug 130725, in commit 1782810f886acd26db211d8fdd7ae8796d203c57.

What happened before was that the *string* "0.95" (which you entered into cell,
and which was stored into/read from the spreadsheet file) was interpreted
incorrectly by the old code, resulting in the value

  0.95000000000000006661338147750939242541790008544921875

instead of

  0.9499999999999999555910790149937383830547332763671875

which is what we get now. You may see, that the old value differs from the
ideal "0.95" by ~6.7E-17, while the new value differs by ~-4.4E-17 - so the new
value is the correct closest representation of the number 0.95, which itself is
not representable in IEEE 754 double-precision binary number.

When later the subtraction happened, with its own expected error (see the FAQ
mentioned in comment 2, and the Wikipedia page referenced from there), the
result happened to match the wrong representation of 0.95 - by pure luck.

In general - it is the programmer's error to compare floating-point numbers
using plain "="; one needs to use comparison with an epsilon in this case -
e.g.,

    If Abs(balance - CellA3.Value) < 1E-10 Then

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to