Bug 39293 - Big integers do not subtract correctly
Summary: Big integers do not subtract correctly
Status: RESOLVED DUPLICATE of bug 37923
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected)
3.3.2 release
Hardware: x86-64 (AMD64) All
: low enhancement
Assignee: Not Assigned
Depends on:
Blocks: 32866
  Show dependency treegraph
Reported: 2011-07-16 17:00 UTC by Fausto Barbuto
Modified: 2020-09-28 22:58 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:
Regression By:

A spreadsheet containing the rows described above (5.96 KB, application/vnd.oasis.opendocument.spreadsheet)
2011-07-16 17:00 UTC, Fausto Barbuto

Note You need to log in before you can comment on or make changes to this bug.
Description Fausto Barbuto 2011-07-16 17:00:04 UTC
Created attachment 49191 [details]
A spreadsheet containing the rows described above

I have a spreadsheet with several big integers, some having 21 digits.

One cell contains 1491038293021230; another contains 1491038293021220.  Their difference should be 10.  However, the subtraction of these 2 cells yields zero.
Gnumeric does it right.

I'm not at all sure if this is really a bug.  I tried to use LibreOffice Help to verify the maximum number of digits an integer can bear, but couldn't find anything.

One thing is for certain: some people (like me) take for granted that if a cell accepts a 21-digit integer this number (and the operations on it) is correct and valid. I came across this "bug" by pure chance, otherwise I wouldn't have noticed it.

Thanks a lot and keep up the good work.

Comment 1 Rainer Bielefeld Retired 2011-07-17 00:10:03 UTC
Unexpectedly NOT reproducible with reporters sample and "LibreOffice 3.4.1  - WIN7  Home Premium (64bit) German UI [OOO340m1 (Build:103)]". I am astonished that such big integers will be calculated correctly, I thought with internal number format "Double" such big integers can not be calculated in a reliable way, somewhere with more than 14 digits results should become unreliable?

I copied / Pasted numbers from original report to cells B1:B2 and subtracted in B3, result was 10 as expected. 

Even when I modified second number in WRITER (added each 1 one by one ) and pasted to B2, result remained correct in my few tests. 

But when I created the subtrahend by a calculation (B3 = B2 + D2) and then calculated B1-B3, I saw the expected inaccuracies.

This is not a bug, for details see.

So more or less DUP of "Bug 32866 - [TASK]: Improve precision for calulation with big numbers"
Comment 2 Rainer Bielefeld Retired 2011-07-17 00:13:30 UTC
But Currently this is not a bug, but expected behavior.
Comment 3 Jeffrey 2011-07-17 17:58:55 UTC
LibreOffice 3.4  340m1(Build:103) on OpenSuse Linux.

Followed what Rainer did, got similar results. Problems do not occur using numbers, but do occur using formulae.
Comment 4 Markus Mohrhard 2011-07-18 05:27:47 UTC
This isn't a bug. It's mathematical problem, when you subtract two nearly identical numbers in floating point arithmetics you may get zero instead of a number that is nearly zero compared to the original numbers.

I'm a bit concerned because this happens a bit too early but not too much.
Comment 5 Björn Michaelsen 2011-12-23 13:25:46 UTC
Since all new unconfirmed bugs start in state UNCONFIRMED now and old unconfirmed bugs were moved to NEEDINFO with a explanatory comment, all bugs promoted above those bug states to NEW and later are automatically confirmed making the CONFIRMED whiteboard status redundant. Thus it will be removed.
Comment 6 Owen Genat (retired) 2014-02-04 01:56:31 UTC

*** This bug has been marked as a duplicate of bug 37923 ***
Comment 7 b. 2020-09-28 22:58:52 UTC
sorry for stepping into an old bug, just for clarification: 

the values in the sample sheet are not integers, but display strings for rounded calculation results, a square of a number ending in '5' should end in '5', thus '25' instead of the '30', and a result from xxx6 * yyy7 * 4 / 2 should end in '4', thus 1491038293021224 instead of the rounded 1491038293021220, 

(nobody spotted that?) 

old versions of calc did more wrong rounding than recent, but as we deal with 'floats' there is no guarantee, 

in most situations calc keeps more precise values internally for calculation, 

starting from that point it's clear that calc's calculation will deviate from users expectation, 

another erro:, as calc and all spreadsheets are limited in the storage for a number there will always be a biggest integer, taken that and added something will result in a value which needs another format to store, with probably less precision, leading to results deviating from users expectations, 

21 decimal digits i've never seen in calc,