Description: Calc performs a wrong calculation using the BIT.XOR function Steps to Reproduce: Create a spreadsheet, like the one I'm going to attach. In it: 1.Create a column of values increasing from -1 to +1, increasing in 0,2 steps 2.On a column next to this, insert the formula: =(A1*100)*(A1*100) and replicate in on the entire column 3.On a column next to this, insert the formula: =BIT.XOR(A1; 1) and replicate in on the entire column Actual Results: C7 results in "398". It is a wrong result! Expected Results: C7 should result in "401", just like the C5 cell Reproducible: Always User Profile Reset: No Additional Info: This doesn't happen if you directly use the formula "=BIT.XOR((0,2*100)*(0,2*100); 1)", which correctly results in 401.
Created attachment 146032 [details] test case
The document contains values with precision errors, like the calculated value 400 in B5 was stored as office:value="400.000000000001"; the calculated value 400 in B7 was stored as office:value="399.999999999999". A manual =BITXOR(399.999999999999, 1) also produces 398, same as =BITXOR(399,1) Recalculating (Shift+Ctrl+F9) the document after load produces correct values here on Linux. Saving the recalculated document results in correct office:value="400" and office:value="6400" in all cases. The test case document was generated using LibreOffice/6.0.6.2$Windows_X86_64 Is this reproducible for others? Btw, also the calculated value 6400 in B2 was stored as office:value="6400.00000000001", the calculated value 6400 in B10 was stored as office:value="6400"; which both are stored as office:value="6400" after recalculating.
The same thing on Version: 6.2.0.0.alpha0+ Build ID: 3846561f79cf9065abd9ca83c9fbfbe7e52e28e2 CPU threads: 4; OS: Linux 4.15; UI render: GL; VCL: gtk3; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2018-10-21_02:45:54 Locale: en-US (ro_RO.UTF-8); Calc: threaded If recalculating (Shift+Ctrl+F9) the document produces correct values. But WHY this change? Why the figures change on a saved document?...
I tested with LO 6.0.6.2 / Windows 7, and got the correct values. Even typed/filled in the initial numbers/formula, so not just opened the file and recalculated the results. Both were fine. Version: 6.0.6.2 (x64) Build ID: 0c292870b25a325b5ed35f6b45599d2ea4458e77 CPU threads: 16; OS: Windows 6.1; UI render: GL; Locale: hu-HU (hu_HU); Calc: CL
Additional information: Original bug was encountered and reported from my office PC, which is a Core i7-920 on Windows 7 Pro SP1. I tried opening the testcase.ods file from my home PC, Core i7-6700k on Windows 10 Pro 1803, and got the same results. I confirm that recalculating with CTRL+SHIFT+F9 produces the right values here too, but simply opening the file I get the wrong ones.
Sorry, I forgot to mention: on my home PC I have LibreOffice 5.4.7.2 x64. The 6.0.6.2 version on my office PC is an x64 one too.
(In reply to diego.guella.85 from comment #5) > Additional information: Original bug was encountered and reported from my > office PC, which is a Core i7-920 on Windows 7 Pro SP1. I tried opening the > testcase.ods file from my home PC, Core i7-6700k on Windows 10 Pro 1803, and > got the same results. I confirm that recalculating with CTRL+SHIFT+F9 > produces the right values here too, but simply opening the file I get the > wrong ones. The formula results are cached in the spreadsheet, so just opening the file will produce wrong results everywhere, unless Calc is set to always recalculate formula. What is interesting is what happens when you recalculate, if the results are fine then, then that particular system+LO combination is okay.
(In reply to Aron Budea from comment #7) > (In reply to diego.guella.85 from comment #5) > > Additional information: Original bug was encountered and reported from my > > office PC, which is a Core i7-920 on Windows 7 Pro SP1. I tried opening the > > testcase.ods file from my home PC, Core i7-6700k on Windows 10 Pro 1803, and > > got the same results. I confirm that recalculating with CTRL+SHIFT+F9 > > produces the right values here too, but simply opening the file I get the > > wrong ones. > The formula results are cached in the spreadsheet, so just opening the file > will produce wrong results everywhere, unless Calc is set to always > recalculate formula. What is interesting is what happens when you > recalculate, if the results are fine then, then that particular system+LO > combination is okay. I wasn't aware about that. So, I recreated the spreadsheet from a blank one on the Core i7-6700K Win10 Pro 1803, LO 5.4.7.2 x64, and I found no issues on the "0,2" row.
Should this be closed given the comments? It's unclear if this is a one-off file that is not clear how it went awry (and thus no need to have an open bug report) or if it's a consistently reproducible problem across multiple files.
Let's close. It can't be reproduced and it's unclear how and with which version those values initially were written (and not just loaded and saved without recalculation).
OK. I confirm that I tried today to recreate the testcase by following my own instructions, and I haven't been able to reproduce it any more, both on my office PC and on my home PC.