https://bugs.documentfoundation.org/show_bug.cgi?id=55960
--- Comment #22 from Mike Kaganski <mikekagan...@hotmail.com> ---
(In reply to b. from comment #21)
> thanks for your comment, sorry for objecting, please correct me if i'm
> wrong,
Please don't. There's no need to be sorry for any objecting.
> from a file saved with ver. 7.1, three cells with values:
>
> B3: -2
> B4: -1,95
> B5: 0,05
>
> content.xml:
>
> ...
> ...
>
> trailing zeroes are truncated on save, but the info about the significant
> decimals keyed in by the user is visible there, besides the values being
> denominated as 'float' i 'see' pure decimal 'fixed point' fractions there,
I doubt that this is "info about the significant decimals keyed in by the
user". Rather, it's the number rounded to some number of decimals on save,
which happens to coincide. Or even possibly a result of smart float-to-string
algorithm finding shortest string that round-trips to the same float.
> as well as 'value' as as 'text',
Of course. When it's output, the output is text of a cell.
> starting with theese values it is technically possible to calculate -0,05 as
> correct result after 39 additions of 0,05 to -2, instead of
> -0,0499999999999998, as calc just did,
This would require to perform these operations related to obtaining shortest
string representation at calculation time, with related unacceptable penalty.
> but ... calc misses both targets and can claim neither correctness nor ex$el
> compatibility ...
In the area of floating-point calculations and related rounding errors, there's
no goal in either math correctness in the strong sense (only in the IEEE 754
sense), nor in "Excel compatibility" (it could only be possible if we know
exact sequence of the calculations they perform, like if they do it from
left-to-right then top-to-bottom, or top-to-bottom then left-to-right, or any
other way for a given argument number of SUM). An error bound to rounding
errors caused by given correct order of computation is OK; if you can suggest
an optimization that gives better precision by re-arranging calculations,
without performance loss - it's fine to discuss in a dedicated issue like
"Function FOO can give better precision", with analysis of correctness of
suggested optimization, and comparison of performance and precision of old and
new ways.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
