[Libreoffice-bugs] [Bug 137679] Implement a Kahan summation algorithm to reduce the numerical error in the total

[bugzilla-daemon at bugs.documentfoundation.org]

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

--- Comment #61 from dante19031999 at gmail.com ---
(In reply to b. from comment #60)
> add. tests: 
> 
> see already '1; 0,1; -1; 1; 0,1; -1; ...' failing, by ~5E-15, 
> and all similar sequences up to '1E15; 0,1; -1E15; ...' increasingly, while 
> '1E16; 0,1; -1E16; ...' and '1E17; 0,1; -1E17; ...' hold. 
> 
> are you at any point trapped by calcs 'built in prettyfiing'?

I finally understood what is going on when you told 1E16 and 1E17 hold.
You've got the chance of falling on what I would call a numerically unstable
zone.
Check this out:
https://en.wikipedia.org/wiki/Double-precision_floating-point_format
It basically says IEEE754 has 15,955 decimals.

Which means, for E16 and E17 you are falling out of range and 0.1 is being
summed at the error term. So all the info is perfectly being kept and you get
the good result.

However, if you are on E+15, you fall on the sum interval. Which means the last
bits of the sum and the error term are modified. That combined with 0.1 not
having exact binary representation you are accumulating error because of finite
precision. If you change 0.1 by 0.25 or 0.125 you get the good result.

I believe my example worked by pure chance because a unexpected convenient
correction of the error because of the order of the sum.

I'm afraid even Kahan Sum has it's limitations. Sorry to disappoint.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20210511/22c75bc7/attachment.htm>