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

[bugzilla-daemon at bugs.documentfoundation.org]

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

--- Comment #16 from b. <newbie-02 at gmx.de> ---
(In reply to Mike Kaganski from comment #15)
> (In reply to b. from comment #14)
...
> =1E+016 - 1 - 1E+016 gives 0, while
> =RAWSUBTRACT(1E+016;1;1E+016) gives -1;

good pinpointing, thanks, sometimes i have a feeling about a problem but am
short in bringing it precisely 'to the point', 

> This is due to natural processing order of the arguments of a function in
> Calc, 

*uggghhhhh*, that's a 'big point'!, sorry, some of the following is OT for
'Kahan' but 1. have to write it somewhere, 2. it's affecting 'Kahan' too, 

some points, where i can't decide which is more important, 

1. if that - special 'right to left processing' - is really in all functions it
might affect more results, (it is in processing of ranges and affects ex$el
compatibility, see tdf#140691), 

2. it is - in some respects - effective and intelligent to work that way, but
contradicts 'normal occidental way of thinking', and a central point of good
programming is not only to be 'somehow circumstantially explainable "right"',
but to deliver what the user knows, understands, needs, what best matches his
expectations and 'normal mathematics'. 

3. there is! a mathematical convention that operations of the same priority
(exponention before 'point calculation' before 'dash calculation'), if not
ordered by brackets, are to be processed 'from left to right', isn't it?. 

4. it is questionable whether calc's calculation of a sum '=sum(A3:D3)' in the
order D3 + C3 + B3 + A3 is compatible with this convention ... ('=sum(D3:A3)'
is not supported by calc, the input is changed arbitrarily).

5. compatibility - it would make sense if different spreadsheets produce
'similar' results, and deviations to 'the big' can be justified with
'mathematically correct' or 'better', but hardly with anything else. 

> (that is *unspecified* by ODF!) 
is a shortcoming as processing sequence affects results, doe's IEEE say
something about that? 

> (which is not complex by the way, just needs an easy hacker to handle it).
in principle 'Kahan' is simple, but knitting it in the big and complex code
base and all the idiosyncrasies of calc could be difficult and requires a
experienced dev, - imho - 

> "alternative" fix that would make a single person in the universe happy).

Please don't always insult me as too idiosyncratic, 'exotic' or too individual,
I don't deal with these topics for fun, but so that errors can be eliminated
and less people suffer from them and the consequential errors of what the
developers were not sufficiently aware of when programming. I could not know
beforehand how deep the causes of any problems lie, but i'm sure it's necessary
to dig to the bottom. The more problems remain in basic functions the more crap
they inject into more complex functions that build on them. 

If you can point me to an concise explanation where is explained how calc works
with details about deviations to 'standard math' i'd possibly ask less silly
questions ...

-- 
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/20210420/bbbe45ae/attachment.htm>