Thanks for this context, Joe. And, truth be told, the fact there was a discrepancy between the textual and code descriptions of the operation may well have been my error. (I don't have a clear memory either way, but it's the sort of text I would have worked on rather than Bill.)
In any case, I think everyone is now agreed on "the right thing" for going forward. --Guy On Aug 28, 2013, at 9:48 PM, Joseph Darcy <joe.da...@oracle.com> wrote: > Hello, > > On 8/23/2013 1:36 PM, Guy Steele wrote: >> The specification of java.lang.Math.round in the first edition of the >> Java Language Specification is quite clear: >> >> public static int round(float a) >> The result is rounded to an integer by adding 1/2, taking the floor of >> the result, and casting the result to type int. >> In other words, the result is equal to the value of the expression >> (int)Math.floor(a + 0.5f) >> >> and a similar statement for the case where the type of the argument is >> double. >> >> This does not correspond to "rounding away from zero" as in IEEE754. >> >> The phrase "ties rounding up" entered the Java documentation later on >> as a (perhaps unfortunately worded) shorthand for the original specification. > > To give some context, the original specification was changed in JDK 7 under > bug > > JDK-6430675 Math.round has surprising behavior for 0x1.fffffffffffffp-2 > http://bugs.sun.com/view_bug.do?bug_id=6430675 > > At the time, it was making the rounds that Math.round gave a "wrong" answer > for an input value equal to the largest floating-point value less than 0.5: > Math.round(0.49999999999999994) returned 1 rather than 0. The result is wrong > in terms of being unexpected; it was the result mandated by the operational > definition of the specification. > > I addressed JDK-6430675 by changing the implementation and removing the > operational definition of Math.round. While I thought I had ruled out > unexpected round-off behavior at the other end of the range, mea culpa, I did > not account for the issues reported in 8010430. > > -Joe > >> >> --Guy Steele >> >> >> On Aug 23, 2013, at 4:24 PM, Dmitry Nadezhin <dmitry.nadez...@gmail.com> >> 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 ? >>> >>> >>> On Fri, Aug 23, 2013 at 10:32 PM, Brian Burkhalter < >>> brian.burkhal...@oracle.com> wrote: >>> >>>> This message follows the RFC >>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-August/019560.htmlposted >>>> on August 2. >>>> >>>> The issue is http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010430. >>>> >>>> The proposed patch http://cr.openjdk.java.net/~bpb/8010430/ has the >>>> effect of option (A) in the aforementioned RFC. >>>> >>>> Thanks, >>>> >>>> Brian >