[Libreoffice-bugs] [Bug 130725] ImpSvNumberInputScan::StringToDouble may produce inaccurate result

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=130725

b. <newbie-02 at gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |newbie-02 at gmx.de

--- Comment #33 from b. <newbie-02 at gmx.de> ---
Created attachment 169318
  --> https://bugs.documentfoundation.org/attachment.cgi?id=169318&action=edit
testing_subtraction_fails_with_random_values

hello @Mike Kaganski, 

i did - testing - see attached sheet, green: good, yellow: ok, red: bad, 

not 4 trillion numbers, that wouldn't have been enough as i would have to work
through the square of these possibilities for subtractions alone, but a
significant sample, about a million problematic cases, randomly assembled, ~96
percent fails in calc (all tasks except the binary trivial ones), 100 percent
correct with some 'auxiliary calculating', i think that's meaningful, 

preliminary note: i appreciate your talents as a programmer and your knowledge
about LO calc very much and would like to praise you in the highest terms, and
to the same extent your condescending arrogant attitude towards others gets on
my nerves to such an extent that i would like to shake you over the head until
it falls off, 

please excuse me for trying relatively persistently to contribute to the
correctness of calc's calculation results, they are still a little too weak
after 35 years of development, 

point of contention 1: calc calculates errors, we agree on that, they are
caused by the 'floats' and 'doubles', i think also 'agree', 'on which aspect'
we can already argue, you think more 'conversion and representation' and thus
unavoidable, i see mostly 'cancellation' as the! problem and one can work on
that, 

point 2: are better results possible? you say 'rather not', i say 'yes, see
attachment', with 'formula' within the IEEE standard (15 significant digits)
100 percent correct results, calc 'standard': about 96 percent fails, outside
the standard (sheet2, 16 digits) the improvements are not yet fully worked out, 

point 3: you say 'such things, effort, rounding and performance impact? NO!', i
say once neatly regulated saves so many stupid questions that the effort is
worth it, and the performance of the hardware has increased so much that we can
afford some computing time for mathematically correct results (we also waste
some on background shading and calculating the positioning of comments), 

point 4: performance: what is said to users stumbling over fp-inaccuracies? do
appropriate rounding, what does that do on performance? kill ... 

point 5: performance I: i have something in the quiver / in development what is
much better than these rounding crutches, i.e. something that achieves the same
but is much faster, but while working on it i keep stumbling over things like
rounding errors, 4-bit truncation, inaccurate comparisons that hinder the
elaboration and verification, so it's not yet ready, 

besides: IEEE 754 defines calculations with 15 sig.-digit figures? thus your
sample '= 0.0043 - 0.0042' means '= 
0.00430000000000000 - 
0.00420000000000000' and for that a result of 
0.0000999999999999994 is correct once you round it to the appr. number of
digits  and! replace the deviating double representation with that of 
0.00010000000000000

besides: i spotted another irritation, '=4/46' displayed as 0,0869565217391304
with 16 decimal digits, and 0,086956521739131 !! *1*, wrong rounding? !! with
15 decimal digits, do you know how come? new bug? 

regards, 


b.

-- 
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/20210131/8ffb19ff/attachment.htm>