[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
----------------------------------------------------------------------------
                 CC|                            |erack at redhat.com,
                   |                            |rb.henschel at t-online.de

--- Comment #12 from b. <newbie-02 at gmx.de> ---
hello @Regina Henschel, hello @erAck, 

hope it's ok cc-ing you, i see @erAck as senior programmer and remember @Regina
as interested in and with knowledge about Standards, 

i see a problem with operand ordering, have discussed in private with @Mike
Kaganski, we can agree: 

- there is a rule in which order operands of e.g. sums over ranges have to be
processed:
https://docs.oasis-open.org/office/OpenDocument/v1.3/cs02/part4-formula/OpenDocument-v1.3-cs02-part4-formula.html#__RefHeading__1432166_1318037074,
there section '4.11.12 Sequences', 

- calc disregards this rule by calculating e.g. '=SUM(A1:A3)' not in the order
A1 + A2 + A3, 

- the calculation order is important because different sequences of the same
operands sometimes produce different results (non-associativity), 

insofar 'not standard compliant', 'not ex$el compatible' and 'difficult to
control for users because results are not predictable', 

we disagree if the argument list of a formula has to be processed in a certain
order, 

Example: '=RAWSUBTRACT(A1; A2; A3)' calculates calc as 'A1 - A3 - A2', 

I think it makes sense to make this intuitive for the users or 'according to
normal mathematical logic', also I see 'When processing a ReferenceList, the
references are processed in order (first, second if any, and so on).' from the
standard applicable here, @Mike Kaganski disagrees. 

If it is not required by the standard so far I plead for it to be included in
future versions, it just makes sense. 

Further one could / should include in the standard: 'the prescribed processing
order may be deviated from if mathematically correct results are achieved with
a different order'. 

(something like that is done by gnumeric ...)

And in calc I plead for a work through and adaptation to the standard, simply
because it is right. I think we cannot wait for the implementation of 'Kahan'
(from which @Mike Kaganski expects a lot) to solve all accuracy problems. that
is good for a 'monolithic', 'smooth' stream of values, for a complex sheet with
complicated interwoven operations and dependencies it becomes ... complex and
complicated. It will not work without storing an additional correction value
for almost every cell, this changes the data structure ... larger project.
There the activation and use of 'long doubles' would be easier to implement?
... imho ...

-- 
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/20210426/c8d0e598/attachment.htm>