<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Precision issue in calc" href="https://bugs.documentfoundation.org/show_bug.cgi?id=138920#c10">Comment # 10</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Precision issue in calc" href="https://bugs.documentfoundation.org/show_bug.cgi?id=138920">bug 138920</a> from <a class="email" href="mailto:jg@jguk.org" title="Jonny Grant <jg@jguk.org>"> Jonny Grant</a> <pre>(In reply to Eike Rathke from <a href="show_bug.cgi?id=138920#c9">comment #9</a>) > We're trying to round and due to the rounding even have some wrong display > strings resulting of the rounding to 15 decimals, but that 0.269985590000001 > *is* already rounded; so yes, the entire display string conversion from > binary IEEE 754 to decimal needs to be reworked, but any "user expects" and > "easy fix" claim is just off. Thank you for you reply. Feels like it's not IEEE rounding that's the issue, it's LibreOffice code, as you say wrong precision is being used, and is then even in the copy paste buffer! Why doesn't the LibreOffice code just use the correct decimal place it already knows? 8.9818 has 4 decimal places. 9.25178559 has 8 decimal places. Seems simple to me, use the 8 decimal places LibreOffice already knows? Here is another example of this issue: =9.25168559 - 8.9818 0.269885589999999</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>