commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Luc Maisonobe (JIRA)" <j...@apache.org>
Subject [jira] Commented: (MATH-151) MathUtils.round incorrect result
Date Sun, 11 Jun 2006 09:04:30 GMT
    [ http://issues.apache.org/jira/browse/MATH-151?page=comments#action_12415733 ] 

Luc Maisonobe commented on MATH-151:
------------------------------------

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 Java-related 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.55e-15 and it would have been 4.54e-15 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: 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message