Created attachment 84471 [details] Bug with a quick summ I often use quick summ feature in my everyday work. It's very useful to select numbers by mouse and get result quickly in a statusbar. But it seems to be buggy ))) There are details in attachment
tested under Win7 64bit. you are right... I get the same "strange number" (-2,8421......) as you. however I see the same also in previous LibO releases up to 3.3.3 changing platform and version. adding Calc expert to CC list.
Simple imprecision error. You get these a lot with binary floating point numbers as they can't represent all decimal numbers exactly. The SUM() function provides a special inaccuracy treatment of some near 0 results which the Quick-Sum does not.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: *Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.1 or later) https://www.libreoffice.org/download/ *If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior *If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT *Update the version field *Reply via email (please reply directly on the bug tracker) *Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-04-01
*** This bug has been marked as a duplicate of bug 69807 ***
Btw. the =SUM(A1:A5) in the file does not return 0, but -2,8421709430404E-14
Created attachment 170464 [details] file to demonstrate calculating order influence unduping as it's not a common 'fp-math-imprecision' error, but two things, 1. as @erAck stated rounding may be different between sheet and statusbar, 2. 'statusbar' calculates in a different order than 'sheet', and as fp-math is mostly not associative this causes differences, more important: ex$el calculates in another order different from both used in calc, thus compatibility problems are unavoidable,
*** Bug 109189 has been marked as a duplicate of this bug. ***
b.: why do you think this would qualify as an easy hack and thus added needsDevEval?
*** Bug 141614 has been marked as a duplicate of this bug. ***
(In reply to Buovjaga from comment #8) > b.: why do you think this would qualify as an easy hack and thus added > needsDevEval? copied that from 109189 in duping, to not get it lost in a bug fading away from scope ... wrong? pls. change acc. usual needs ...
Reproduced in recent master build with both attachments: Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: da006fbe2d4c5891933390d72f6e6026b28d39fc CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-08-19_11:31:56 Calc: threaded Adding meta bug 86066.
Dear arj, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
This actually is worse now: The SUM() function now also reports a wrong value on the given example files: example: -170.87 -223.73 -12.58 234.98 172.2 =SUM(A1:A5) => -1,59872115546023E-14 Quicksum now reads -2.8421709430404E-14
(In reply to C.Drewke from comment #13) > This actually is worse now: > > The SUM() function now also reports a wrong value on the given example files: > > example: > -170.87 > -223.73 > -12.58 > 234.98 > 172.2 > > =SUM(A1:A5) => -1,59872115546023E-14 > > Quicksum now reads -2.8421709430404E-14 my current version: Libreoffice 5.5.2 (X86_64)
Opening attachment 84471 [details] with a recent LO Dev 24.2, I can see the result of the SUM() is displayed as -1.59872115546023E-14. On the same file, I type in the exact same values on a new column and perform the equivalent SUM(); the result of SUM() is displayed as 0 (zero) exactly. Expanding the columns' width makes no difference. Subtracting each individual value (between the original values in the file and the newly-typed-in values) also returns 0 (zero) for each pair. Hard Recalculate shows no difference. The differences between the SUM() function and the status bar is not a surprise, but (at least to me) the difference between the two SUM() functions is, especially after Hard Recalculate.
=RAWSUBTRACT(0;A1;A2;A3;A4;A5) gives 2.8421709430404E-14 that is the "raw" subtraction with IEEE 754 double values. The status bar does the same. =A1+A2+A3+A4+A5 gives 0 as individual operator+ and operator- calculations try to tie the result to 0 if applicable. =SUM(A1:A5) gives -1.59872115546023E-14 using the Kahan summation algorithm. The problem here is A1 being the formula =-170.87, replacing that with value -170.87 also =SUM(A1:A5) results in 0. Apparently since LO 7.2 when Kahan summation was introduced. Which generally gives more accurate results than the previous SUM() algorithm. Need to investigate the cause and what could be done about it.
(In reply to Eike Rathke from comment #16) > Apparently since LO 7.2 when Kahan summation was introduced. Which generally > gives more accurate results than the previous SUM() algorithm. > > Need to investigate the cause and what could be done about it. I guess this requires a new, different bug report, rather than using this tdf#68448.
Right, I created bug 156985.
A: Of course it's still there if you don't do anything about it. B: After 13 years! C: We should stop asking about errors with clearly identified causes over and over again: Is it still there? Is it still there? Is it still there? D: And why add further inconsistencies in every small detail to a system with an out-of-control codebase that annoys users with inconsistencies, further aggravating the codebase and further confusing users? E: Otherwise, you could always offer three different results with the comment "we can't calculate, choose what you like..." Errors would then always be the user's fault.
(In reply to b. from comment #20) > A: Of course it's still there if you don't do anything about it. > > B: After 13 years! > > C: We should stop asking about errors with clearly identified > causes over and over again: Is it still there? Is it still there? > Is it still there? No, we shouldn't stop. In a study by the QA team, 25% of mass-pinged reports could be closed when all of them were tested.