Java 8 RFR 8010430: Math.round has surprising behavior for odd values of ulp 1
Dmitry Nadezhin
dmitry.nadezhin at gmail.com
Fri Aug 23 20:44:11 UTC 2013
I guess that the method java.lang.Math.round() should correspond to
roundToIntegralTiesToAway of the IEEE 754-2008. Standard says about it
(section 5.9):
===
roundToIntegralTiesToAway(x) rounds x to the nearest integral value, with
halfway cases
rounding away from zero
===
So the halfway cases are n + 0.5 ( like -1.5, -0.5, +0.5, +1.5).
Standard says that roundToIntegralTiesToAway rounds them to (-2,-1,+1,+2).
On Sat, Aug 24, 2013 at 12:32 AM, Brian Burkhalter <
brian.burkhalter at oracle.com> wrote:
> With respect to this issue, the argument satisfies the condition
>
> a == (int)a
>
> or
>
> a == (long)a
>
> so there really is no tie, unless I am missing something. The problem is
> that in the current implementation the intermediate result
>
> a + 0.5
>
> is rounded according to the IEEE standard so the conditions above are no
> longer true.
>
> On Aug 23, 2013, at 1:24 PM, Dmitry Nadezhin wrote:
>
> > The specification of java.lang.Math.round() says
> > * Returns the closest {@code int} to the argument, with ties
> > * rounding up.
> >
> > It is not clarified what is "ties rounding up".
> > I guess that it should correspond to the direction "roundTiesToAway" of
> > IEEE 754-2008
> > and to the java.math.RoundingMode.HALF_UP .
> >
> > They round
> > +0.5 -> +1
> > -0.5 -> -1
> >
> > The current implementation of java.lang.Math.round() rounds
> > +0.5 -> +1
> > -0.5 -> 0
> >
> > "ties rounding up" should match IEEE754 standard and other JDK math
> class,
> > shouldn't it ?
>
>
More information about the core-libs-dev
mailing list