[ http://issues.apache.org/jira/browse/MATH-151?page=comments#action_12415048 ]
Luc Maisonobe commented on MATH-151: ------------------------------------ I think this behaviour is normal. Despite 39.245 has a finite representation in decimal, this is not true in base 2, it has a infinite number of digits. For the sake of simplicity, here is the representation in base 16 (much more readable than base 2) : 0x27.3EB851EB851EB851EB851... Note that the pattern EB851 repeats itself ad infinitum, in base 2 it is a 20 bits pattern. If this number could be represented in a virtual infinite register, multiplying it by 100.0 (base 10) would be multiplying it by 0x64 (base 16) and the result would be 0xF54.8 which is 3924.5 as could be rounded as expected. However, primitive doubles are represented in Java using the IEEE754 norm, where the mantissa is 53 bits long, counting an implicit first bit. This implies that in the previous infinite number only the following is represented in IEE754: 0x27.3EB851EB851 hence, when this number is multiplied by 100, we get the result: 0xF54.7FFFFFFFFA4 or 3924.49999999999477040546480566263198... So the error is exactly 0x0.0000000005C or 92/16^11 which is approximately 5.229e-12. The problem comes from the fact the original number cannot be represented exactly (it is not what is sometimes called a "floating-point number" or "normal number"), and in this case the first neglected hexadecimal digit is large (E) which explains the large error (7 wrong bits after the multiplication). I would say this is not an issue with commons-math but with IEE754, we cannot do anything about it. Note that the same would occur if we could add one pattern by adding 20 bits. In this case, the final number would be 3924.4999999999999999950126700065666 and the error appoximately 4.987e-18 (92/16^16), but still lesser than 3924.5 > MathUtils.round incorrect result > -------------------------------- > > Key: MATH-151 > URL: http://issues.apache.org/jira/browse/MATH-151 > Project: Commons Math > Type: Bug > Versions: 1.1 Final > Environment: Win2K, Sun JDK1.5.0_05 b05 > Reporter: Buza Zoltán > > MathUtils.round(39.245, 2) results 39.24, however it should be 39.25, with > default rounding mode BigDecimal.ROUND_HALF_UP. > I found that internally MathUtils.round multiplies the given number by > 10^scale. > 39.245 * 100.0 results 3924.49999...5 , and after this the calculation is > not correct any more. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
