[Libreoffice-bugs] [Bug 50299] MOD shows not existing, inconsistent, small remainder with calculated Dividend
bugzilla-daemon at bugs.documentfoundation.org
bugzilla-daemon at bugs.documentfoundation.org
Fri Oct 16 09:39:37 UTC 2020
https://bugs.documentfoundation.org/show_bug.cgi?id=50299
b. <newbie-02 at gmx.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |newbie-02 at gmx.de
--- Comment #42 from b. <newbie-02 at gmx.de> ---
Created attachment 166404
--> https://bugs.documentfoundation.org/attachment.cgi?id=166404&action=edit
a proof of concept to correct (some) fp-conversion errors by smart rounding
posting here as i couldn't find or overlooked the 'new report',
proposal for better results at the bottom of this post,
the OP bug seems! fixed in ver. 7.1, sample
libreoffice_bug-50299_test-document-showing-modulo-bug.ods calculates
correctly,
but try mod(24,09;1), expand the result cell until you see 0,0899999999999999,
it is still buggy,
results in newsample.ods: evolve from invalid summation, at least 0,2+0,1 and
0,7+0,1 inject small 'decimal to binary-float conversion artefacts', mod just
makes them visible, sample produces better results in ver. 7.1,
libreoffice_bug-50299_modulo-bug.ods: impressive how much work already was
invested in theese issues, calculates better in ver. 7.1, needs a recalc to
clear outdated results loaded from file,
in 'mod and modfast proposition.ods' i see some fp-imprecision artefacts with
divisors 3, 4, 6, 7, 8 and 9, not clean with ver. 7.1, clean if you use 'MOD_S'
from attached sample, check red and green marked cells D27 vs. F27, and
F30:F32,
BugDecimalDateTest.ods: just expand col H until you see 8,99999999999999 in the
critical cells, the date function looks like more doing cut or truncation of
it's arguments than rounding, and thereby aggravates the error and makes it
visible, but the source cause is the inaccurate decimal -> fp conversion, or
the inaccurate [overaccurate ;-) ] MOD() result, this still happens in ver.
7.1,
@Rainer Bielefeld wrote - long time ago and prophetical:
'All this does not mean that it's impossible to use hardware with limitations
in a more smart way, but that's not a simple fix. Research will go on, may be
some day someone will find a way to sail around those reefs.'
i'm not going to stick that badge to my jacket, but i'd like to push
improvements, either enable a 'decimal-safe' datatype in calc, or take
something like the 'smart rounding' shown in the attached sheet (with 'user
code functions') implement it in code - and faster - (looking up the decimal
places of the arguments and rounding results to the mathematical correct
length),
that will surely have a negative performance impact, but irritated users asking
correct questions about incorrect results ever and ever again are a performance
issue as well - imho the bigger one -
if you want to satisfy all wishes just implement an option switch for
'performant vs. precise' calculation, then it's up to the user to choose his
poison,
the option 'precision as shown' is already an attempt in that direction, it
covers plenty problems, but not all, and it introduces new ones because it is
only useful in cases where the user can make reasonable assumptions about the
number of digits in the results, other tasks are made worse, especially if the
user isn't aware / has forgotten that this function is active,
i would really appreciate if someone takes the time to check the approach with
the macros, are there errors?, 'just try to break it' ...
@Rainer Bielefeld: i liked slide rulers too, they are precise enough for
bridges (calculate to five digits and then double the result to stay safe), and
they avoid 'unintelligent' cutting, rounding, truncating made by machines but
use 'smart rounding' by humans in analog, that works.
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20201016/11995bcf/attachment.htm>
More information about the Libreoffice-bugs
mailing list