JDK 9 RFR of JDK-8164524: Correct inconsistencies in floating-point abs spec
Hans Boehm
hboehm at google.com
Sat Aug 20 23:40:43 UTC 2016
The new specification presumably does not guarantee that
Float.floatToRawIntBits(Math.abs(x)) ==
Float.floatToRawIntBits(Math.abs(x))
when x is a NaN, instead leaving that to quality of implementation.
Intended?
I'm OK with either answer. Just asking to confirm.
On Sat, Aug 20, 2016 at 4:10 PM, joe darcy <joe.darcy at oracle.com> wrote:
> On 8/20/2016 3:16 PM, Martin Buchholz wrote:
>
>>
>>
>> On Sat, Aug 20, 2016 at 12:32 PM, Martin Buchholz <martinrb at google.com
>> <mailto:martinrb at google.com>> wrote:
>>
>>
>> Quibble: "guaranteed" may be true in practice,
>> but longBitsToDouble is technically permitted to reset the sign
>> bit back to 1 if the hardware is hostile. Because of this, I would
>> simply remove the word "guaranteed".
>>
>>
>> After reading IEEE 754 2008 6.2.1. , I now believe signalling NaNs have
>> to use the significand bits; the sign bit is free to use; and so I retract
>> my quibble, and am happy with the word "guaranteed".
>>
>
> Right; the sign bit of a NaN has very little meaning. The hardware guys
> like to be able to do things like for a floating-point multiply "sign bit
> of output = XOR of sign bits of inputs" without having to do inconvenient
> NaN checks :-) The NaN payload for retrospective diagnostics is all in the
> significand.
>
> Cheers,
>
> -Joe
>
>
More information about the core-libs-dev
mailing list