When a user enter fractional values in a spreadsheet, they expect the representation of that value to be exact, not an approximation by a base-2 representation like FP32 (IEEE 754 single-precision) FP64 (double-precision) etc. They meant the exact value they entered. Similarly, when a user sets a cell to the result of an additive formula involving decimal values (immediate or via cell reference), they expect the result to be exact, not approximate. For example, users expects the formula =(3100099 - 3200012)*0.01 to yield 99913 , which it does. But users also expect =3100099*0.01 - 3200012*0.01 to yield the same value... which it does not. This second formula yields -999.1299999999970000 instead of -999.13 Now, it is true that if a user is somewhat knowledgeable in matters of representation, they would understand why this happens. But most users are not; and moreover - this is not the user's _intent_. Now, obviously, a binary computer cannot perform infinite-accuracy computations, so there must be limits to our "indulgence". However - we are far from where this limit should be. A user is likely to accept that when they use trigonometric, exponential, logarithmic and other such functions - accuracy will be imperfect (and, in fact, most users don't try any of that stuff intentionally). At the very least, I argue that computations all of whose steps maintain representability in decimal form should be performed with perfect accuracy. This would require two "bigint"s for (signed) mantissa and base-10 exponent. Other possibilities could be: * Divisor and dividend * mantissa, exponent and basis (so, three "bigint"s) ... now, I know what you're going to say: It's a huge change, it's really fundamental, it goes against half of everything we've written for 35 years, nobody will ever have the time to spare to seriously work on this - maybe. But it's the right thing to do in principle. And as for mitigating the pain: * The default could change with a new ODF version, so that old documents maintain existing behavior. * There would be a choice of underlying representation model, e.g. for compatibility and for lovers of binary. * It could start as an opt-in before it becomes the default. See also bug 128312.
(In reply to Eyal Rozenberg from comment #0) > ... now, I know what you're going to say: It's a huge change, it's really > fundamental, it goes against half of everything we've written for 35 years, > nobody will ever have the time to spare to seriously work on this - maybe. > > ... > > See also bug 128312. Huh? You yourself provided a link to the bug report, where this was answered. And even putting aside the fact that your suggestions do not change things - there will still be only a limited accuracy - the only thing discussed there was not "it's huge work", but - only performance.
See also recent bug 155795.
Dear Eyal Rozenberg, 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