[Libreoffice-bugs] [Bug 140691] calc: calculation: sequence of operations neglected in many tasks, only mathematical better results should be allowed if calc differs from ex$el | was: sum of range: (and similar) - no compatibility with ex$el reg. ordering of operands

[bugzilla-daemon at bugs.documentfoundation.org]

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

b. <newbie-02 at gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|calc: calculation: sum of   |calc: calculation: sequence
                   |range: (and similar) - no   |of operations neglected in
                   |compatibility with ex$el    |many tasks, only
                   |reg. ordering of operands   |mathematical better results
                   |                            |should be allowed if calc
                   |                            |differs from ex$el | was:
                   |                            |sum of range: (and similar)
                   |                            |- no compatibility with
                   |                            |ex$el reg. ordering of
                   |                            |operands

--- Comment #7 from b. <newbie-02 at gmx.de> ---
@Mike Kaganski: 

i won't accept a 'wontfix', 

i'm aware that it's a difficult thing, but it's a general problem which needs
care and awareness, what - imho - was neglected yet, 

ex$el compatibility might be no goal for you, but most users demand it, and
it's been a decisive argument in many other questions, if calc stays away from
it in this respect it should be clearly communicated to the developers,
supporters and users, 

as far as it's a matter of 'standards' it's a clear weakness of them, and
should be argued about to change and how to define, 

as far as there are three concepts conflicting with each other (backward
compatibility to calc vs. ex$el compatibility vs. progress and mathematical
correctness) ... there is hardly another way than to wake awareness for that
and implement three different modi, which each address one target without
compromising, 

as far as you suggest to aim at mathematically correct results as a concept
against lazy compromises - which you often liked to wipe aside as too exotic or
too difficult - i'm fully behind you, changing subject, two tips: 
- this would also affect the backwards compatibility inside calc, 
- have a look at gnumeric, they have solved this point better, 

> This must be WONTFIX.
- see above, 

> We do not try to follow the order of evaluation that Excel does, when it's unspecified in any standard. 
- i know it's hard for an arrogant person like you, but pls. consider that in
some way ex$el is a 'de facto standard' in the world we have, 

> They may have different data layout that makes their specific order more efficient, and our data layout may make another order preferred; 
- yeah, and it's time to get that noticed and be aware of, 

> also they may change it tomorrow, without notice. 
- i can't believe you really believe that, they are! ... 'somewhat problematic'
... but not stupid enough to shock all their users and break their! backward
compatibility, 

> It's for purpose that various standards do not define the order of evaluation.
- on purpose? too difficult so far? or just forgotten? - if you say 'on
purpose': 1. evidence please, 2. what purpose? 

> And then, if you think that it would "improve compatibility", then you are breaking compatibility with our documents. Then, what about Excel following the order used in Calc when opening ODS?
- i admit it's a difficult thing, i'm yet short to know the ultima ratio, but i
know it's relevant to care for, 
- imho it's not a problem of the file, but of calculation sequence at runtime,
as of now i expect the results stored in the files to be different if saved by
calc or ex$el, 

> It's just splitting hairs, and is absolutely useless to pursue this. 
- no, it would reduce plenty of problems we - and the users - are facing today,
at least being aware of such things, 

> As said in the bug 55960 comment 22 cited here in comment 0, we only worry about real problems, 
- it is! a real problem, 
  - as it affects results, and 
  - as you haven't been aware of it, 

> and suggestions that allow to improve calculations. 
- i hope you won't start citing Adolf Hitler? who once spouted such nonsense
as: 'Only the one who can solve a task better is entitled to criticism.' 
no, we all make better progress if even the people who can not yet eliminate
errors are allowed to point them out. 

> E.g., Excel gives 0 for SUM(1e20;-1;-1e20) and 1 for SUM(1e20;-1e20;-1), and it would be just fine for Calc to start producing proper -1 for both; 
- that sentence gives some hope you change your stubborn mantra 'fp-math is
imprecise, it has to stay like that' (i know that you worked for progress, need
not to mention, but you humiliate and demotivate other people who try to do
this to an extent ... well, we've talked about this before ... shake you ...)  

> trying to mimic Excel here is *not* a goal (which would be, if we accept this bug).
- it's a quite easy 5 step concept: 
1. users demand what they understand, 
2. they would understand correct math, 
3. they would accept wrong result like ex$el, 
4. they will complain about wrong results different than ex$el, thus: 
5. to avoid 4. while you can not reach 2. try 3. (reaching 2. would be better
...) 

doe's 'needsDevEval' say 'easyhack'? then pls. remove, thought 'evaluation by
devs'

-- 
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/20210421/38ecbece/attachment-0001.htm>