JDK 9 RFR of JDK-8164524: Correct inconsistencies in floating-point abs spec

[Hans Boehm]

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
>
>