https://bugs.freedesktop.org/show_bug.cgi?id=86005
--- Comment #5 from Jindrich Svorc <[email protected]> --- (In reply to Robinson Tryon (qubit) from comment #4) > (In reply to Jindrich Svorc from comment #3) > Sure, but you aren't representing 0.45 or 0.6 as floating-point numbers :-) Right, ok, that explains it. Thank you. I thought the floating number should give you exact result. No additional rounding needed. But apparently it is not valid in all cases. It might make sense to round it for N-1 bits. Just one additional comment, It was not visible anywhere that the number in the cell is actually 0.999999999980 and not 1. I am not sure whether it is deliberately but it was difficult to find the root-cause. Even the sum in the status bar showed 1. Maybe if the INT function round the number for 14 decimal places before it is applied it can help. But I am not sure whether I can foresee all the consequences. Thanks for explanation. > > > Interestingly, if you change the equation to get result = 2 it calculates it > > correctly. > > Indeed! Look at this: > (8.45-8)/0.6 -> 0.749 999 999 999 999 000 00 > > 0.45/0.6 -> 0.750 000 000 000 000 000 00 > (7.45-7)/0.6 -> 0.750 000 000 000 000 000 00 > > (3.45-3)/0.6 -> 0.749 999 999 999 999 000 00 > (9.45-9)/0.6 -> 0.749 999 999 999 999 000 00 > > > I would not care too much since I usually don't need the 15th place but the > > problem is that INT function gives me 0 instead of 1 so it suddenly creates > > a big difference. > > Perhaps you could use 10 or 15 places of precision? That should hopefully > round the number up or down as expected... -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
