[ http://issues.apache.org/jira/browse/MATH-151?page=all ]
Luc Maisonobe updated MATH-151:
-------------------------------
Attachment: math-151.patch
This patch is an attempt to solve the issue.
The principle is to add a nexAfter method in MathUtils and to use it in order
to very slightly shift the numbers (by one ulp) in the expected rounding
direction in order to avoid some degenerate cases.
Note that if someone REALLY wants to round a number like
39.2449999999999974420461512636 and NOT 39.245, we will produce a wrong result.
I didn't put any warning about this behaviour in the javadoc, but I think that
if this patch is finally applied, the javadoc should be exlpicit.
I understand the user problem but do not really like answering like that, it
seems more like an ad hoc trick to me. I'm not very proud of my first patch :-(
> 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
> Attachments: math-151.patch
>
> 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]
