Bug 68448 - Calculating error. wrong quick summ result in statusbar
Summary: Calculating error. wrong quick summ result in statusbar
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected)
3.3.0 release
Hardware: x86-64 (AMD64) All
: low minor
Assignee: Not Assigned
: 109189 141614 (view as bug list)
Depends on:
Blocks: Statusbar
  Show dependency treegraph
Reported: 2013-08-22 19:50 UTC by arj
Modified: 2023-08-29 10:48 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:

Bug with a quick summ (10.25 KB, application/vnd.oasis.opendocument.spreadsheet)
2013-08-22 19:50 UTC, arj
file to demonstrate calculating order influence (7.00 KB, application/vnd.ms-excel)
2021-03-13 20:47 UTC, b.

Note You need to log in before you can comment on or make changes to this bug.
Description arj 2013-08-22 19:50:05 UTC
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
Comment 1 tommy27 2013-08-23 15:56:11 UTC
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.
Comment 2 Eike Rathke 2013-08-23 21:27:42 UTC
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.
Comment 3 QA Administrators 2015-04-01 14:40:47 UTC Comment hidden (obsolete)
Comment 4 Buovjaga 2015-04-22 14:01:07 UTC

*** This bug has been marked as a duplicate of bug 69807 ***
Comment 5 Buovjaga 2015-04-22 14:04:41 UTC
Btw. the =SUM(A1:A5) in the file does not return 0, but -2,8421709430404E-14
Comment 6 b. 2021-03-13 20:47:11 UTC
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,
Comment 7 b. 2021-04-13 15:30:47 UTC
*** Bug 109189 has been marked as a duplicate of this bug. ***
Comment 8 Buovjaga 2021-04-13 15:43:31 UTC Comment hidden (obsolete)
Comment 9 b. 2021-04-13 17:08:57 UTC
*** Bug 141614 has been marked as a duplicate of this bug. ***
Comment 10 b. 2021-04-13 17:24:05 UTC Comment hidden (obsolete)
Comment 11 Stéphane Guillou (stragu) 2021-08-20 14:06:46 UTC
Reproduced in recent master build with both attachments:

Version: / 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.
Comment 12 QA Administrators 2023-08-21 03:05:39 UTC Comment hidden (obsolete)
Comment 13 C.Drewke 2023-08-25 08:13:48 UTC Comment hidden (obsolete)
Comment 14 C.Drewke 2023-08-25 08:16:27 UTC Comment hidden (obsolete)
Comment 15 ady 2023-08-25 13:55:57 UTC Comment hidden (obsolete)
Comment 16 Eike Rathke 2023-08-28 11:15:12 UTC Comment hidden (obsolete)
Comment 17 ady 2023-08-28 11:44:34 UTC Comment hidden (obsolete)
Comment 18 Eike Rathke 2023-08-29 10:48:00 UTC Comment hidden (obsolete)