Hello list members,
Regina Henschel wrote:
[...]
Please have a look at
http://www.openoffice.org/issues/show_bug.cgi?id=88119
After looking to this bug and some further testing I came up with more
intriguing issues.
kind regards
Regina
I added some comments to the aforementioned issue. Here is a more
detailed account of what I am thinking is happening. I might be wrong.
1.) write 2 float numbers from the keyboard, e.g. 8.1 and 8.2
2.) select them and drag the lower right corner to create the number 8.3
in the adjacent cell
3.) write in a different cell from the keyboard the number 8.3
4.) display the two "8.3" numbers with 18 decimals (this is overkill)
5.) compute the following differences:
= 10 * ( "8.3 from keyboard" - 8 )
= 10 * ( "8.3 from fill" - 8 )
RESULTS
[IMPORTANT: DO NOT SAVE THE SPREADSHEET]
Both numbers are equal and are: 8.300000000000000000
BUT
Strangely, the two differences are:
= 2.999999999999990000 and
= 3.000000000000010000
Yep, they are different. Computing "8.3 from keyboard" - "8.3 from fill"
results in 0.00000..., aka 0
So, are these numbers identical or NOT???
And IF YES, why do they behave differently?
Now, save the spreadsheet. Magic did happen, and both numbers are
identical and indeed behave as when identical.
What causes me headaches is the fact that Calc aggressively rounds
numbers off, even IF they are NOT really 0.
As previously posted, I do NOT have a strong opinion IF this is
detrimental or actually benefits the user. It is surely detrimental IF
done on accurate statistics on large data sets, BUT for most financial
spreadsheets I actually believe it is a wise handling.
My problem is: IF Calc aggressively rounds numbers off, so will he
round the automatically generated numbers. I am thus puzzled that the
two "8.3" 's behave differently.
HYPOTHESIS
==========
My hypothesis is:
1.) Calc rounds the numbers when they are displayed in the spreadsheet
2.) AND when the spreadsheet is Saved
3.) BUT keeps an internal buffer with the originally computed number
which gets used when the "8.3" is used in further
mathematical calculations
Now, IF Calc uses internally 32-bit float precision, this is good. BUT,
in the case of auto-filling, the buffer should be cleared and populated
with the rounded value.
This is however just my guess, because I do NOT know the internal data
handling. I hope that my comments will further the understanding in
this area, ultimately leading to the correction of this issue.
Indeed, Calc (and ODF) should handle automatic filling operations with
utmost care, because this is something users heavily rely on, and the
process is covered with a lot of pitfalls.
Sincerely,
Leonard
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
