[Libreoffice-bugs] [Bug 55960] Filling cells with incremental numbers – wrong numbers

[bugzilla-daemon at bugs.documentfoundation.org]

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

--- Comment #21 from b. <newbie-02 at gmx.de> ---
(In reply to Mike Kaganski from comment #20)
> (In reply to b. from comment #19)
> > or are values stored as floats there too?
> 
> This. Calc is not a key logger.

hello @Mike Kaganski, 

thanks for your comment, sorry for objecting, please correct me if i'm wrong, 

from a file saved with ver. 7.1, three cells with values: 

B3: -2
B4: -1,95
B5: 0,05

content.xml: 

... 
<table:table-row table:style-name="ro1">
   <table:table-cell/>
   <table:table-cell office:value-type="float" office:value="-2"
calcext:value-type="float">
      <text:p>-2</text:p>
   </table:table-cell>
</table:table-row>
<table:table-row table:style-name="ro1">
   <table:table-cell/>
   <table:table-cell office:value-type="float" office:value="-1.95"
calcext:value-type="float">
      <text:p>-1,95</text:p>
   </table:table-cell>
</table:table-row>
<table:table-row table:style-name="ro1">
   <table:table-cell/>
   <table:table-cell office:value-type="float" office:value="0.05"
calcext:value-type="float">
      <text:p>0,05</text:p>
   </table:table-cell>
</table:table-row>
... 

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, 

as well as 'value' as as 'text', 

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, 

even with a 'fuzzy' floating point calculator: 

algorithm 1: 
take -2 
repeat 39 times: 
   [add 0,05 
   round to two decimals] 

algorithm 2: 
take -2
take -1,95
calculate difference
round to two decimals
calculate result times 39
round to two decimals
add to -2
round to two decimals

i accept that you are much deeper in the project and code and have profound
knowledge, i see that you did! work to enhance this point, 

but above sample is one of plenty where i - and some other 'simple minded
users' - don't understand why calc 'insists in producing obviously wrong
results', 

looking at the complaints here and in 'ask' and their long history and how time
consuming it is for devs and supporters to deal with theese complaints, and
estimating how many other users are irritated without expressing it and how
many may turn away from calc or spreadsheets in general ... 

i can't understand why there is such poor success in efforts to produce correct
decimal results ... as it would be so easy ... (imho, please correct me if i'm
wrong), 

sorry for the long post, i'd like to bring long lasting problems to points
where they are either solved or proven as unsolveable, 

to calm down: ex$el is only slightly better in these things, in this test it
has only one error in the first 62 lines instead of three (calc), and the first
error occurs in line 42 instead of 39 (calc), tested with ver. 2010, winx64, 

but ... calc misses both targets and can claim neither correctness nor ex$el
compatibility ...

-- 
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/20200903/d23e3f07/attachment.htm>