Java 8 RFR 8010430: Math.round has surprising behavior for odd values of ulp 1

[Guy Steele]

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.

--Guy Steele


On Aug 23, 2013, at 4:24 PM, Dmitry Nadezhin <dmitry.nadezhin at 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.burkhalter at 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