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. Fausto
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. <https://bugs.freedesktop.org/show_bug.cgi?id=32862#c1> So more or less DUP of "Bug 32866 - [TASK]: Improve precision for calulation with big numbers"
But Currently this is not a bug, but expected behavior.
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.
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.
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.
*** This bug has been marked as a duplicate of bug 37923 ***
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,