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

[Guy Steele]

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.darcy at 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.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
>