Enter the following numbers and formula: A1: 31415926535897932384 A2: 31415926535897900000 A3: =A1-A2 Expected number in A3: 32768 (not 32384 because of floating-point roundoff). Actual number in A3: 0. Both cells display 3.14159265358979E+019 when edited. If you try to subtract 31415926535897932384 from 31415926535897967616, the latter number is turned into 3.1415926535898E+019, but the difference is still 0. The ulp of those numbers is 4096; it should be possible to enter two numbers that size whose difference is 4096. When a floating-point binary number is converted to decimal for later conversion back to floating-point binary, it should be converted with enough digits that conversion to floating-point binary results in the same number. In this case, the number should be displayed in the edit box as 3.1415926535897932E+019.
(In reply to phma from comment #0) > Expected number in A3: 32768 (not 32384 because of floating-point roundoff). > Actual number in A3: 0. maybe related to: Bug 96918 - Rounding display error for 15 digits integers https://ask.libreoffice.org/en/question/156399/decimal-precision-how-to-have-18-decimals/
The minus operator does an approxSub() within the order of magnitudes of the two operands (i.e. ties/pulls to zero), as users expect 0.3-0.2-0.1 to be 0.0 If you use =RAWSUBTRACT(A1;A2) the result is 24576, which is just the "raw" floating point subtraction of two values. Adhoc I'm not sure if and what could be done about the input and display of such large values, as the largest unambiguous integer value representable as IEEE 754 double is 9007199254740991 or (2^53)-1. Not directly related to bug 96918 as that was about displaying the representable integer values accurately. > When a floating-point binary number is converted to decimal for later > conversion back to floating-point binary, it should be converted with > enough digits that conversion to floating-point binary results in the > same number. In this case, the number should be displayed in the edit > box as 3.1415926535897932E+019. That is wishful thinking. An IEEE 754 double can not be more accurate than general 15 decimal digits, sometimes 16 and rarely 17 decimal digits. The problem with unique strings convertible back to double is that they are even less accurate and not what users expect. See http://blog.reverberate.org/2016/02/06/floating-point-demystified-part2.html You might also be interested in some other links under https://erack.de/bookmarks/D.html#Computer_Arithmetic_and_IEEE_754 and https://erack.de/bookmarks/D.html#010203 If you have a perfect solution I'm not aware of then please tell us.
(In reply to Eike Rathke from comment #2) > You might also be interested in some other links under > https://erack.de/bookmarks/D.html#Computer_Arithmetic_and_IEEE_754 and > https://erack.de/bookmarks/D.html#010203 > > If you have a perfect solution I'm not aware of then please tell us. phma: please let's hear the perfect solution or close this report.
Created attachment 166902 [details] sheet showing 'values' are there, and 'precision gap', hello @Buovjaga, 'phma: please let's hear the perfect solution or close this report.' imho demanding 'the **perfect** solution' is a little overstretching, but *better* solutions are! possible, and i support the request of @phma demanding that ... see attached sheet, setting 'new',
Created attachment 166903 [details] sheet showing calculation is possible, and 'precision gap' sorry, calc in a way trashes the input by changing the input string and after save-load the value is gone :-( tried to circumvent by 'value()',
just looked at the sheet after re-downloading: looks like it needs a recalc for B4 and B5 or general to show the different values, different differences with different versions of calc, 6.1 / 7.1, funny ...
Dear phma, 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 bug is still present in version 7.3.7.2 (package in Ubuntu Jammy) and 6.4.7.2 (package in Ubuntu Focal).
This bug is still present in 7.3.7.2 (Ubuntu Jammy) and 6.4.7.2 (Ubuntu Focal).