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.nadez...@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.burkhal...@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 ?
>>
>>
