Description: <v>57.374999999999993</v> and default format 0,00 Opens by: LO >= 7.4 is 57.37 LO 7.3.7.2 is 57.38 Excel is 57.38 Actual Results: 57.37 Expected Results: 57.38 Reproducible: Always User Profile Reset: No Additional Info: -
Created attachment 191019 [details] Simple sample Open in with LO >=7.4 and in LO 7.3. See difference
*** This bug has been marked as a duplicate of bug 158190 ***
(In reply to Mike Kaganski from comment #2) > > *** This bug has been marked as a duplicate of bug 158190 *** Is this issue really dup of round() issue? Here is not used round(). This is just a file from Excel. 1. Excel show 57.38 and LO show 57.37 2. If I change value, but restore 57.375 and save cell, I see 57.38 3. If I save and reopen I see 57.38 4. If I set option "Precision as shown" then =A1*100 will be 5738 This is really wrong!
Yes you are right. It is different. While rounding to 2 decimals here looks technically correct (it is smaller than 57.375), the problem of changing the value on save-and-reload is real.
Seems to have started with: https://git.libreoffice.org/core/+/9eb9083ff2fdaeb96399a0830a4394de4e29ef64 author Mike Kaganski <mike.kaganski@collabora.com> Tue Feb 15 09:20:52 2022 +0300 committer Mike Kaganski <mike.kaganski@collabora.com> Thu Feb 17 21:46:58 2022 +0100 Use Dragonbox to implement doubleTo*String*
(In reply to Gabor Kelemen (allotropia) from comment #5) > Seems to have started with: Started specifically what? The more numerically correct display, or the wrong save?
(In reply to Mike Kaganski from comment #6) > (In reply to Gabor Kelemen (allotropia) from comment #5) > > Seems to have started with: > > Started specifically what? The more numerically correct display, or the > wrong save? The fileopen difference on the attached file. In 7.3 all 4 cells were displayed as 57.38 Since 7.4 the first two A1:A2 are 57.37 the second two A3:A4 are 57.38. Did not check what happens after save.
(In reply to Gabor Kelemen (allotropia) from comment #7) > Did not check what happens after save. Please see comment 4. According to Mike, the problem is about either the file save or the file open, not really about the rounded result (57.37).
(In reply to Mike Kaganski from comment #6) > (In reply to Gabor Kelemen (allotropia) from comment #5) > > Seems to have started with: > > Started specifically what? The more numerically correct display, or the > wrong save? I guess for an XLSX file, the only correct way is to load & display it as Excel does?
(In reply to Thorsten Behrens (allotropia) from comment #9) :-) It may be true, but completely orthogonal to the clarification requested in my question? ;-)
https://gerrit.libreoffice.org/c/core/+/165142 will take care of the display issue. However, let me make this issue strictly about the problem of wrong number roundtrip: the value of 57.374999999999993, that is stored in the original file, must stay 57.374999999999993 (or 57.37499999999999, which represents the same IEEE 754 64-bit binary value) on export, and must not be rounded to 57.375 in the file.
Aha: I already tried to fix the save problem in https://gerrit.libreoffice.org/c/core/+/151383 ...
Dear Maxim Britov, 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