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
