I'm not sure whether it's a bug or not but I'm reporting it just in case. STR: 1. Open https://bz.apache.org/ooo/attachment.cgi?id=69414 from https://bz.apache.org/ooo/show_bug.cgi?id=111533 -> Observed behaviour: C2 shows 8,29999999999995 instead of 8,3. Reproduced in Version: 6.2.0.0.alpha1+ Build ID: 5edc23dbc53773536265fd6a54319d9cd1cd9e99 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded but not in LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4 [Bug found by office-interoperability-tools]
it changed from to 8,3 to 8,29999999999995 in https://cgit.freedesktop.org/libreoffice/core/commit/?id=54862a932fc9ccc1788e91629818ec6666ec1c09 @Eike, @Regina, What's your opinion on this?
i think, it's not a bug, it's a feature: the result is always: 8,29999999999995 change column width (widen column B or decrease C) and the displayed values will change
https://en.wikipedia.org/wiki/Numeric_precision_in_Microsoft_Excel#Subtraction_of_Subtraction_Results
(In reply to Oliver Brinzing from comment #2) > i think, it's not a bug, it's a feature: > > the result is always: 8,29999999999995 > > change column width (widen column B or decrease C) and the > displayed values will change Thanks for checking. I would like to hear Eike's opinion before closing it...
Shrug, binary floating point numbers in most cases do not exactly represent accurate decimal numbers. Subtracting these sample numbers does not produce a "pleasing to the eye" exact value with a large enough number of decimals (which the General format produces with a wide enough column). Any cosmetics (e.g. 14 instead of 15 significant digits to round earlier) would just hide things at yet another place.