Java 8 RFR 8010430: Math.round has surprising behavior for odd values of ulp 1
Dmitry Nadezhin
dmitry.nadezhin at gmail.com
Wed Aug 28 17:55:09 UTC 2013
TLS 1 specification contained verbal statement
"The result is rounded to an integer by adding , taking the floor of the
result, and casting the result to type int".
and Java code
Math.floor(f + 0.5).
It seems to me that the verbal statement says about mathematical "+" .
It maps a pair of reals to there exact sum without rounding.
"+" in Java code is machine adding that is mathematic adding followed by
rounding.
In my opionion this is the source of mismatch.
The verbal TLS 1 statement is equivalent to
"Returns the closest {@code int} to the argument, with ties rounding to
positive infinity".
The Java code "Math.floor(f + 0.5) is not.
This is just a remark.
I agree that formulation "Returns the closest {@code int} to the argument,
with ties rounding to positive infinity" is clear.
On Wed, Aug 28, 2013 at 6:48 PM, Brian Burkhalter <
brian.burkhalter at oracle.com> wrote:
> On Aug 27, 2013, at 7:44 PM, Dmitry Nadezhin wrote:
>
> Is it reasonable to make specification clearer ?
>
> Either to return JLS 1 specification:
> <<<
> The result is rounded to an integer by adding , taking the floor of the
> result, and casting the result to type long.
> >>>
>
>
> This verbiage would imply no change to the implementation with the odd ULP
> unity cases continuing to exhibit the problem described in the issue.
>
> or to replace "rounding up" with "rounding to positive infinity":
> <<<
> Returns the closest {@code int} to the argument, with ties rounding to
> positive infinity.
> >>>
>
>
> This change could accompany the implementation change I posted in the
> updated webrev.
>
> Thanks,
>
> Brian
>
More information about the core-libs-dev
mailing list