Description: while playing around with floating point values i stumbled upon a funny display problem, it looks as if the value is correct, but in display with 14+ decimal places it's displayed as 10,00000000000000E+00 instead of - correct - 1,00000000000000E+00 the error dosn't survice save-load but is reproducible, just follow steps below, don't think over the formula etc., it's an unfinished version, the error can be copied by ctrl-c ctrl-shift-v to other cells, copy text, numbers, date&time, Steps to Reproduce: 1. open attached file (if not in this description see next comment) 2. observe cell BO2, reg. save-load it'll display 1,00000000000000E+00 2a. same for cell BO4, which is two step copy of BO2 3. click on cell BO2 4. F2 5. ctrl-a 6. ctrl-c 7. ctrl-v - enter 8. observe BO2 now displaying 10,00000000000000E+00,that's 10 times too much, 8a. same for BO4 8b. BO3 not affected 9. shrink display of BO2 to 13 decimals 10. observe display now 1,0000000000000E+00 11. enrich display to 14 decimals or more 12. observe value shown as 10,00... istead of 1,00... 13. observe cell BO3, formula '=BO2', displaying 1,00000... regardless of wrong display for BO2, 14. observe cell BO4 having the same 'illness' as BO2, wrong display up from 14 decimals, 15. play around as you like, the error occured only for specific mantissae all zeros ending on ...110 or ...101, sometimes you don't need to paste BO2 but it's sufficient to change the last two bits of the mantissa ... the behaviour is a little different with a different formula, copy e.g. BO8 to BO2, have fun ... Actual Results: cells displayed with 10 times too high value and 'ill' formatting up from 14 decimal places, Expected Results: correct results, Reproducible: Always User Profile Reset: No Additional Info: Version: 6.2.8.2 (x64) Build ID: f82ddfca21ebc1e222a662a32b25c0c9d20169ee CPU threads: 8; OS: Windows 6.1; UI render: default; VCL: win; Locale: de-DE (de_DE); UI-Language: en-US Calc: actual 7.0.0.0.a0+ fails too ...
Created attachment 158655 [details] testfile to produce the bug
Bug is reproducible on Version: 7.0.0.0.alpha0+ (x86) Build ID: d194171917978979ff90400133c2843ae7077db9 CPU threads: 8; OS: Windows 10.0 Build 18363; UI render: Skia/Vulkan; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: CL AND Version: 6.4.1.2 (x64) Build ID: 4d224e95b98b138af42a64d84056446d09082932 CPU threads: 8; OS: Windows 10.0 Build 18363; UI render: GL; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded removed QA:Needscomment from whiteboard. Status changed to NEW.
there is an easier way to reproduce: the value which is erroneously presented is: '1' that's what the mantissa values should - nearly - add up to, minus '2^-52' (for the missing terms 2^-53, 2^-54, 2^-55 ... of the mantissa, in infinite they should add up to 2^-52), minus '2^-51', that's the bit not set in the sample, thus '1 - 2^-52 - 2^-51' should be the same value, and might show the same weakness when displayed in scientific format, and, voila, it does. easy reproducer: copy and paste '=1 - 2^-52 - 2^-51' in a cell, without the quotes, and then set the format to 'scientific' with 14 or more decimal places. fault: with ver. 6.2.8.2 and 7.0.0.0.a0+ : display of 10,00000000000000E+00 (my assumption - sorry @Eike - somewhere a '< vs. <=' or '> vs. >=' error ... in the code to format the display) i saw some other issues with bits from the mantissa having no effect on the fraction or final value, i'll ask for that in 'ask' first. reg. b.
Looks similar to https://bz.apache.org/ooo/show_bug.cgi?id=91100.
@Regina: yeah, thanks, i think it's the same bug, an old bug again :-( still unresolved in AOO? already buggy in LO 4.1.6.2, setting to 'inherited from OOo', could someone check in linux please? looks as if correct display 'til: 1-7,21644966006352E-016, wrong display starting with: 1-7,21644966006351E-016, wrong display 'til: 1-6,10622663543837E-016, display correct again starting with: 1-6,10622663543836E-016 in IEEE 754 notation (sign(1) - exp(11) - mantissa(52)): 0 0 1111111110 11 1111111111 1111111111 1111111111 1111111111 1111111001 holds, 0 0 1111111110 11 1111111111 1111111111 1111111111 1111111111 1111111010 fails, 0 0 1111111110 11 1111111111 1111111111 1111111111 1111111111 1111111011 holds, same for negative values, 1 0 1111111110 11 1111111111 1111111111 1111111111 1111111111 1111111010 fails, binary formula to construct affected value: '=(1+(1-2^-52)-2^-50-2^-52)*2^-1' wrong display occuring in a range of +/- 2^-53 around this value, sometimes values are shown correct after load of file (despite 'recalc on load' not! being set), but become wrong after re-entering the formula, sorry for assumptions, it's not sure to be a LO bug, might also result from: - intel (hardware), - intel (software / library), - gnu c++, - gnu c++ compiler options (i've seen a site saying that performance options have evil affect on fp precision ...) [we have two of ~ 1,843*10^19 values producing a misrepresentation, and i have to stumble upon one of them ... who has given me this 'talent'? and why?]
still an issue in: Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 6e6e531b564cdc9d5b25287c215cdc5a1fcbb346 CPU threads: 8; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: CL
still an issue in: Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: c703b2d22c3f45825d9c9d790c3b5a4b6f97e776 CPU threads: 8; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: and: 'linux too', ver. 7.3.0.0 alpha, setting to HW: all, without having checked Mac and Android, shouldn't such be an easyHack?
I do NOT reproduce with: Version: 7.4.2.3 (x64) / LibreOffice Community Build ID: 382eef1f22670f7f4118c8c2dd222ec7ad009daf CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: fr-FR (fr_FR); UI: fr-FR Calc: threaded whereas I was able to reproduce with Version: 7.2.2.1 (x64) / LibreOffice Community Build ID: 0e408af0b27894d652a87aa5f21fe17bf058124c CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL: win Locale: fr-FR (fr_FR); UI: fr-FR Calc: threaded