commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Luc Maisonobe (JIRA)" <>
Subject [jira] Commented: (MATH-151) MathUtils.round incorrect result
Date Thu, 15 Jun 2006 02:32:30 GMT
    [ ] 

Luc Maisonobe commented on MATH-151:

I was looking for a way to characterize those "bad" IEEE754 representations. Here is one proposal:
we could had an implementation of  the nextAfter method, either in MathUtils or in a new IeeeFunctions
method in case we want also to add other interesting functions defined by the IEEE754 standard.
The signature of this method is:

  static double nextAfter(double d, double direction)

It returns the next representable number after its first argument which lies on the same side
as the second argument. Using this, we could compare the rounding of x and nextAfter(x, x+1)
when the rounding mode is ROUND_HALF_UP. If the results is different, the IEEE754 representation
of x is on some boundary. In fact, I think we could always return the rounding of nextAfter
in this mode (after all if round(x) and round(nextAfter(x)) are the same, we could return
either and if they are not the same, we want to return round(nextAfter, at least in some rounding
methods). The test could be performed in the roundUnscaled method, and similar tests could
be implemented in the other branches of the switch for other rounding methods.

This would be slower than the current implementation, but probably much faster than going
back to rebuild a String and parsing it as a BigDecimal.

I have written an implementation of nextAfter. It is based on Double.doubleToLongBits, bits
twiddling, and  Double.longBitsToDouble.

> MathUtils.round incorrect result
> --------------------------------
>          Key: MATH-151
>          URL:
>      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:
For more information on JIRA, see:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message