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

[Guy Steele]

There seem to be two distinct issues here:

(1) As originally specified in the first edition of JLS, java.lang.Math.round sometimes
accepts an argument that is equal to a mathematical integer and returns a value that
is another (larger) mathematical integer because IEEE rounding occurs in the addition
of the value 1/2.  Arguably this could be regarded as a mistake in that original
specification, and if I understand correctly, this is the point of the logged issue.

(2) Now you have raised the question of whether this same method java.lang.Math.round
"should" be the same as the operation roundToIntegralTiesToAway of IEEE 754-2008,
or some other operation in some version of IEEE 754.  I assure you that such a correspondence
was never the intent of the original specification; the rounding performed by java.lang.Math.round
and by roundToIntegralTiesToAway are two different kinds of rounding (among many others
that are possible), and it is a mistake to think that they "should" be the same.  If we would like
for Java to support the IEEE 754-2008 operation roundToIntegralTiesToAway, then that method
should have a different name; in fact, "roundToIntegralTiesToAway" would be a good name.  :-)

--Guy

On Aug 23, 2013, at 4:44 PM, Dmitry Nadezhin <dmitry.nadezhin at gmail.com> wrote:

> 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.burkhalter at 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 ?
>> 
>>