[ http://issues.apache.org/jira/browse/MATH-151?page=comments#action_12416287 ]
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: 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]
