https://bugs.freedesktop.org/show_bug.cgi?id=87386
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|DUPLICATE |--- Summary|Calculation inaccuracy and |Calculation inaccuracy |inconsistency converting |converting calculated |numbers and text to dates. |numbers to dates and | |integers. --- Comment #7 from [email protected] --- (In reply to m.a.riosv from comment #6) > Please take a look to this bug report just about MOD() function: > > https://bugs.freedesktop.org/show_bug.cgi?id=50299 > > Specially Kohei comment #4. > > Resolved as duplicate, please if you are not agree reopen it. > > *** This bug has been marked as a duplicate of bug 50299 *** Thank you, I've already reopened 50299, with comments 20, 21 & 22, and an attachment showing how the problem is not only a problem, but is worse than many of the other commenters seem to think (in LO Calc 4.4.0 Beta2 Dev Daily, MOD(230,10)=0, MOD(2.3*1000,100)=100). There is clearly an error with how LO Calc calculates the modulo. The problem is not so extreme in Excel. As long as hardware has been around, I doubt Intel and Motorola have been just ignoring postgrad work on fast modulus algorythms (e.g., http://www.dtic.mil/dtic/tr/fulltext/u2/a547555.pdf), so I question hardware as the cause. I am trying to figure out what to tell someone who is familiar with the MOD() function code that will help him/her fix it. So far, what I sure of is that the MOD() function is not rounding the dividend to the correct number of significant digits before doing the math. Real example: =MOD(ROUND(36.3000000000002,9)*100,10) gives the result 10, which is wrong. =MOD(ROUND(36.3,9)*100,10) gives the same result. =MOD(36.8000000000003*100,9),10) gives 2.45563569478691E-011, which you might look better...until you see that =MOD(36.3*100,10) gives 10 However, that's not the problem that caused me to create this bug report, so I am reopening it. Here, the problem appears to be that DATE() (and INT()) do the same thing; not rounding parameters passed as real numbers to the correct number of significant digits before executing the function. Passing a constant real number, doesn't cause so much trouble, but the whole point of functions is to allow working with calculated values, and those tend to be real until you do something special to them to convert them. The program is supposed to do that when it's needed, because it doesn't always display what it's actual result is, so the user has no way of knowing the general number 9 that's displayed is actually 8.999999999999999. MOD(24.09,1) should equal 0.09, although LO Calc displays 0.09 it is using 0.0899999999999999, so 0.09*100 displays 9 but uses 8.99999999999999. Since that 15 digit number is not correct, any function that expects an integer needs to make sure it's rounded correctly. But multiple calculations tend to adversely affect accuracy in more digits, so after 1000 additions, a value (real example) displayed as 100 may be represented internally as 99.9999999999986, so when dealing with significant digits, rounding must be to digits, not to decimal points, and rounding a 15 digit number to 15 places will eventually give a wrong answer. To use 99.9999999999986 in an integer or date function it must be rounded to 11 decimal places or 13 digits. I've done engineering calculations that added many thousands and were still accurate enough so rounding to 13 digits (not decimal places) was sufficient. If you want to see what number you're actually using, just use the formula =""&[cell reference]. -- 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
