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

The point is neither on the rounding method not on the scale factor, it is rather on the initial
number itself.
39.245 has no exact representation in IEE754. it lies between two representable numbers (I
forgot 4 bits in my previous post):
0x139f5c28f5c28f * 2^47 < 39.245 < 0x139f5c28f5c290 * 2^47
or 0x27.3eb851eb851e < 39.245 < 27.3eb851eb8520
or 39.2449999999999974420461512636... < 39.245 < 39.2450000000000045474735088646...
When we talk about 39.245, we refer to the decimal representation that was parsed either by
some data input function using something like Double.parseDouble(String) or we refer to a
litteral value in the Java code, which in fact is also parsed at compilation time, probably
also by double.parseDouble(String) or a similar function. The virtual machine doesn't see
the 39.245 real number we want, it sees either 0x27.3EB851EB851E or x27.3EB851EB8520 depending
on the parsing behaviour. This is not a Javarelated problem, it is also true for languages
like C, C++, fortran, whatever.
In the case discussed here, the value was the low one (i.e. 0x27.3EB851EB851E, or 39.2449999999999974420461...).
The parsing method did a good job here in my opinion as this number is the closest one to
the real number we wanted (the error is about 2.55e15 and it would have been 4.54e15 if
the other alternative were chosen).
Going back to the initial problem, and assuming we now start from 39.2449999999999974420461...,
we want to round this number 2 digits after the decimal point. MathUtils.round answer is 39.24
(really 39.2400000000000019895...), which is "only" 0.0049999999999954525264... away from
out number. Answering 39.25 (which CAN be represented exactly in IEEE754) would be "0.005000000000002557953848..."
away. The initial number is not exactly at a 0.5 * 10^n boundary, so switching between ROUND_HALF_DOWN,
ROUND_HALF_UP or ROUND_HALF_EVEN does not change anything (I have checked this).
> 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
