Description: from https://ask.libreoffice.org/en/question/32183/calc-why-are-bits-killed-in-subtractions-with-heavy-cancellation-and-can-this-be-turned-off/ i learned that: 1. ex$el does 'bit killing' similar to calc but less violent, -> calc isn't fully compatible, 2. you can turn this off in ex$el by enclosing the expression in parentheses, -> calc lags behind the capabilities of ex$el, and is not fully compatible, in calc you can also calculate more exactly by using 'rawsubtract' instead of '-', but this is terribly cumbersome, i think calc should catch up ... and overtake by introducing that for 'sum' over ranges and similar expressions too! the results are not! exact in absolute decimal means, but let it to the user to gain dec-math-correct results '=ROUND((1-0,999999999999999);15)', (even '=ROUND(1-0,999999999999999;15)' holds), calc: ... '=ROUND(RAWSUBTRACT(1;0,999999999999999);15)' ... works ... but produces the bad feeling Thompson, Kernighan and Ritchie try to fool us again Steps to Reproduce: 1. fetch a copy of ex$el, 2. key '=1-0,999999999999999' into a cell, 3. observe result '0,00000000000000000000' (if neccess. adjust format and width to show 20 decimals), 4. key '=(1-0,999999999999999)' into a cell, !parentheses, 5. observe result '0,00000000000000099920' (if neccess. adjust format and width to show 20 decimals), 6. try the same in calc ... :-( Actual Results: ex$el gives the user access to the basic values, calc only with awkward tricks Expected Results: same or better functionality as ex$el, and possibility to work 'compatible' to ex$el to avoid problems when exchanging data / files 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: assume older ver. affected as well, assume linux affected as well,
Looks similar to 140695. Doing further examination.
(In reply to Peter S Anderson from comment #1) > Looks similar to 140695. Doing further examination. hello, thanks for looking, 'similar' - yes, but not the same, that is for excessive 'bit eating', this is about giving the user ability to work without,
No progress for the time being. Probably best to wait until there is some response from higher powers concerning bug 140695.
Hello Dante, is it something your work on KahanSum improves ? Should it be closed as dupe of bug 137679 ?
(In reply to Xisco Faulí from comment #4) > Hello Dante, > is it something your work on KahanSum improves ? > Should it be closed as dupe of bug 137679 ? No. It may be a little bit better because I killed some horrible roundings in some of the affected functions. But everything else stills untouched. I don't know what made all the functions modified, but I'm quite sure that operators like +, -, *, ... are still major data losses.
LibreOffice Calc: A B C 3 B3*C3 53 70% 4 B4*C4 88 30% 5 Round(A3+A4) Vi vidos 63 and not 64 en A5. En aliaj oficejaj pakoj vi ĉiam vidas 64 kiam kalkulite: gnumeric , Excel, OnlyOffice, Google Sheets. You will see 63 and not 64 in A5. In other office packages you always see 64 when calculated: gnumeric, Excel, OnlyOffice, Google Sheets.