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.
Hello, It's been a while since this issue was reported. Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
kidding? how should it improve if none works on it? the provided examples are simple enough to check quicker than changing status and writing comments.
(In reply to gmolleda from comment #6) > 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. I see 64 in cell A5 in Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 85c8901dc2710e91bccb64cd7d8068441f42f65b CPU threads: 32; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: threaded
LO Calc 25.2.1.2: =1-0,999999999999999 -> 0,0000000000000000 in Excel and Calc =(1-0,999999999999999) -> 9,99200722162641E-16 in Excel and 0,0000000000000000 in Calc. Version: 25.2.1.2 (X86_64) / LibreOffice Community Build ID: d3abf4aee5fd705e4a92bba33a32f40bc4e56f49 CPU threads: 4; OS: Linux 6.11; UI render: default; VCL: gtk3 Locale: es-ES (es_ES.UTF-8); UI: es-ES Calc: threaded