[Libreoffice-bugs] [Bug 140691] New: calc: calculaton: 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

            Bug ID: 140691
           Summary: calc: calculaton: sum of range: (and similar) - no
                    compatibility with ex$el reg. ordering of operands
           Product: LibreOffice
           Version: 4.1.6.2 release
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: medium
         Component: Calc
          Assignee: libreoffice-bugs at lists.freedesktop.org
          Reporter: newbie-02 at gmx.de

Description:
spinoff from tdf#55960: 

ex$el (starting with upper left cell in sheet and calculating left->right, then
top->down, oczidental style) and calc (starting with bottom right cell in sheet
and calculating bottom->up and then right->left, oriental style) are different
in simple calculations which are sensitive to the ordering of operands (it's
depending on the operands), e.g.
sum(1234; 0,12; -1234) is sensitive), 
it's not a big problem, might bring bridges down or crash airplanes somewhere
far away, not a big a problem, but it's a little annoying as some people in
some points stated that calc will try to be as good as ex$el or better, and
thus the better choice for users ... for that goal and to ease migration for
users it should be as easy as possible, and should not! inject errors when you
import sheets from one system into the other ...  but it does ... 

citation from tdf#55960: '(it could only be possible if we know exact sequence
of the calculations they perform, like if they do it from left-to-right then
top-to-bottom, or top-to-bottom then left-to-right, or any other way for a
given argument number of SUM)' - ex$el calculates: 
- '=Lx+My+Nz': in the order Lx, My, Nz, as written in the formula, no matter
where the cells are positioned in the sheet, imho calc does the same, 
- '=sum(Ax:Cy)': top row from left to right then next row, imho different to
calc which acts rightmost column bottom up, then nextleft column, i 'assume'
oriental influence, and i'm astonished that nobody mentioned that earlier, as
it indeed introduces compatibility issues, 
ex$el does not: do any smart sorting of operands reg. magnitude or similar as
sometimes somewhere assumed, neither does calc (afaik), 
(above tests with ex$el 2010 ver 14.0.6023.1000 64-bit) 'home and business', 

happy hacking ... :-) 

b. 


Steps to Reproduce:
1. guess how to test, 
2. found a method: test and see, 
3. not found: keep trying or ask me, 

Actual Results:
calculation order different, 

Expected Results:
identical computation sequence to keep compatibility and avoid irritations /
fails, 


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 62dff2844b0bf1d1bcb8eb4d6db529ef4a31bee4
CPU threads: 8; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default;
VCL: win
Locale: de-DE (de_DE); UI: en-US
Calc: 

didn't test versions prior 4.1.6.2, assume 'inherited', 
didn't test linux or mac, assume 'all', 
didn't reset user profile, assume apparent on more then one system -> not
'local corruption',

-- 
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/20210227/fefc9e8f/attachment.htm>