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.burkhal...@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 ? > >