[Libreoffice-bugs] [Bug 87506] Inconsistency in how LibreOffice Calc 4.4.0BetaDevDaily handles real numbers internally or with the MOD() function or both.

[bugzilla-daemon]

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

b.  changed:

   What|Removed |Added

 CC||newbie...@gmx.de

--- Comment #3 from b.  ---
@klsu: if you select cells C1 or C2 and look at the input line you will see a
deviation, 
you may also get it visible with: '=RAWSUBTRACT(B2;E2)', 
calc does some 'tolerant compare' to cover such small imprecisions, but keeps
the odd value and uses it for downstream calculations, one can argue the hour
and the day whether well done or not, 
the source of evil is 'cancellation', and that no spreadsheet has good handling
for that so far ... :-(

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 87506] Inconsistency in how LibreOffice Calc 4.4.0BetaDevDaily handles real numbers internally or with the MOD() function or both.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=87506

k...@cox.net changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 87506] Inconsistency in how LibreOffice Calc 4.4.0BetaDevDaily handles real numbers internally or with the MOD() function or both.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=87506

k...@cox.net changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|DUPLICATE   |---
Summary|Inconsistency in how|Inconsistency in how
   |LibreOffice Calc|LibreOffice Calc
   |4.4.0BetaDevDaily handles   |4.4.0BetaDevDaily handles
   |real numbers internally.|real numbers internally or
   ||with the MOD() function or
   ||both.
 Ever confirmed|0   |1

--- Comment #2 from k...@cox.net ---
I agree that this appears to be the same as bug 87506, which is marked
resolved; however, if you read that bug you will find that it is not resolved.
As I understand that discussion, their resolution is, it's a hardware problem
that can only be fixed in software, which isn't worth doing because it's slow
(but then why does Excel, which is fast, not have the problem on the same
hardware).

What I find particularly interesting is this:
in cell A6 enter 0.3
in cell B6 enter =MOD(A6*100, 10)
cell B6 displays 3.5527136788005E-015
in cell A6 enter =3/10
cell B6 displays 0

So letting the hardware create the 0.3 instead of using LO Calc's stored 0.3
gives the correct answer. That doesn't prove it's not a hardware bug, but it
proves it is or is also a software bug, and I have confirmed that it exists in
LO 4.4.0 Beta Dev Daily I installed 2014-12-18 AND in Excel 2003, but not as
bad. More on that when I reopen 87506 with a spreadsheet example showing just
how bad the LO Calc MOD() function can be.

Same result using 0.6 vs 6/10

"We can't fix it or don't think it's worth fixing, so mention it in the
documentation and it's resolved" does not resolve the problem. Explaining it to
the average person wouldn't help them, if they ever happen to read it (have you
read and understood and remembered all the documentation of every piece of
software you use?). They would understand "if you use the MOD() function, the
answer might be right and it might not be, so you'd better check every use of
the MOD() function manually", which means "don't use MOD(), it's not reliable".

The correct resolution would be to remove the MOD() function from LO Calc until
it has been fixed.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs