[Libreoffice-bugs] [Bug 140695] New: calc: calculation: calc wrong results and less precise / accurate than ex$el?

[bugzilla-daemon at bugs.documentfoundation.org]

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

            Bug ID: 140695
           Summary: calc: calculation: calc wrong results and less precise
                    / accurate than ex$el?
           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:
i'm starting to get the bad feeling that: 

- most developers don't care if calc produces wrong results on the simplest
computational tasks ... 

- and that they propagate 'IEEE double precision' accuracy even though they
know it's not true,  

calc: 
'=99999999,9999999 - 99999999,9999998' -> 0,000000000000, 

weitz.de/ieee (64 bit mode):  
99999999,9999999; 99999999,9999998; '-' -> 8.940696716308594E-8, round that to
7 decimals digits and you are 100% accurate, calc: 100% fail, 

maybe it can motivate that calc is weaker than ex$el (calculates less
accurate): 

- in the above task ex$el fails too, but:  
'=99999999,9999999 - 99999999,9999997' they can! do in Redmont, 

while calc can't even compute:  
'=99999999,9999999 - 99999999,9999996', result still '0',  

isn't that a bit embarrassing?  

no, no, no, NO! ... no stupid comments like 'fanboy' please, i am NOT!!! here
because i want to have everything like this rip-off company, i am here because
i want to support a better product ... 'the spreadsheet you ever wanted', 'the
spreadsheet that fulfills your needs' ... 

please, please, please! ... give us our 15-digit accuracy back ... 

and 

please, please, please! ... if you need to do some rounding here or there ...
do ROUNDING! (at best accurate rounding), no silly truncations ... 

it would make calc a better spreadsheet, and this world a better one ... 

!!! other more complicated calculations build on correct results of such simple
tasks ... such errors undermine the reliability of calc in general !!! 

such things have to be solved first, the search for other errors is hopeless or
at least very difficult as long as the basics don't work, solutions there
degenerate to guessing games or 'trial and error' mumbo jumbo and! inject
errors in other areas that only later become apparent ... a downward spiral ... 

at least! 15 digit accuracy please, no compromises ...!

shall / can we introduce a 'round-trip check' like for the dec -> bin -> dec
conversion of values? the result of a calculation is correct if it holds in the
inverse calculation, i.e. "z as result of '=x - y' is only accepted if '=z + y'
results in x again"? 

but then - please - with reliable comparisons, not with a calc which calculates
'=99999999,9999999 = 99999999,9999996' to 'true' without turning red.

didn't test versions prior 4.1.6.2 but assume 'inherited' (hey guys, such stuff
dates back to 16- and 32-bit systems),  

didn't test linux but assume 'all',  

didn't reset user profile as error is stable and apparent in different versions
and installations, 

Steps to Reproduce:
1. see above description, 
2. calculate '=99999999.9999999 - 99999999.9999998' in calc, 
3. calculate the same with 'weitz' (www.weitz.de/ieee), 
4. if you don't trust weitz (it's calculating with possibly buggy math
libraries on your! computer (javascript?)), recalculate with pencil and paper
or switch on brain and try mental arithmetic


Actual Results:
'0' :-(

Expected Results:
at least! IEEE 754 compliant results, at best 'decimal correct': '0,0000001',  


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:

-- 
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/7a16a5bb/attachment-0001.htm>