https://bugs.documentfoundation.org/show_bug.cgi?id=158219
Bug ID: 158219
Summary: Calc should default to using another representation
over FP64 (double precision floating-point)
Product: LibreOffice
Version: Inherited From OOo
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: Calc
Assignee: libreoffice-bugs@lists.freedesktop.org
Reporter: eyalr...@gmx.com
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.
--
You are receiving this mail because:
You are the assignee for the bug.
