https://bugs.documentfoundation.org/show_bug.cgi?id=141614
b. <newbie...@gmx.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Hardware|x86-64 (AMD64) |All
OS|Linux (All) |All
CC| |newbie...@gmx.de
Version|6.4.6.2 release |Inherited From OOo
Resolution|--- |DUPLICATE
Status|REOPENED |RESOLVED
--- Comment #14 from b. <newbie...@gmx.de> ---
IMHO 68448 and 109189 fit better as ancestors,
@TheWebMachine: your values are mostly 1.2 or multiples, the 'double'
representation of 1.2 is short by about
4.4408920985006261578426667835888095E-17, thus expect some deviation,
expect additional deviation as the smaller of two summands mostly looses some
bits in the addition, the effect on the running total is changing with the
accumulated value in the total - size ratio of the two summands, that decides
about the 'bin-range-change' for the smaller summand, if the change results in
a loss of a bit-string starting with zero it's simply truncated and the total
runs short, if the chopped part starts with '1' the part taken into account is
rounded up and the total grows more than it should,
'in sheet' the deviations are often rounded away or covered by 'snap to zero'
or invisible in short cell format or similar, for 'previous sum plus 1.2' i get
visible fails starting with row 46 (display 20 decimals), rawsubtract can
detect deviations from row 9 on, in ex$el (2010) the deviations start with row
49,
in the statusbar the totals are less rounded? (acc. @erAck) and calculated in
another order which reg. 'non-associativity' may produce different results ...
'fun with floats and doubles' ...
help: round your results, request a 'fail free working round', learn hacking
and reprogram the statusbar calculation ...
@Mike Kaganski: 'Kahan Summation' may! help as a: it's not limited to different
magnitude, and b: the difference running total / summands will likely grow
while all summands are positive ...
@TheWebMachine:
'If you can't add 1.5 to 1.5 and get 3' - that's easy, all values have exact
representation in doubles,
'Ex$el and other apps have been adding FPNs for aeons and seem to get it
working right just fine' - seem to but don't, believe me, see comment above
about ex$el. the handling is sometimes somewhat different, but the math and
it's problems is the same, and difficult to deal with. i wouldn't say
impossible, but difficult, and ex$el suffers from such too.
it is! a bug, it is! a duplicate of already filed bugs, it is! a difficult
task, and it likely won't! be solved in near future as it's a: low priority,
and b: already old (8 years), if it would have been easy most likely someone
would have done it in the meantime ...
*** This bug has been marked as a duplicate of bug 68448 ***
--
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
