[ http://issues.apache.org/jira/browse/MATH151?page=comments#action_12415048 ]
Luc Maisonobe commented on MATH151:

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.229e12.
The problem comes from the fact the original number cannot be represented exactly (it is not
what is sometimes called a "floatingpoint 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 commonsmath 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.987e18 (92/16^16), but still lesser than 3924.5
> MathUtils.round incorrect result
> 
>
> Key: MATH151
> URL: http://issues.apache.org/jira/browse/MATH151
> 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, email: commonsdevunsubscribe@jakarta.apache.org
For additional commands, email: commonsdevhelp@jakarta.apache.org
