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

[joe darcy]

Hello,


On 8/20/2016 4:40 PM, Hans Boehm wrote:
> 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?

The normative specification says if the argument to abs is a NaN, the 
result is a NaN; no guarantees are made about the bits of the NaN. 
Therefore, the identity above is not guaranteed to be true for NaN value 
of x, but would likely usually return true in practice for a given 
platform implementation. (One way it could fail to be true is if one 
Math.abs was replaced by an intrinsic and the other one was not and the 
intrinsic and the non-intrinsic implementation had different NaN handling.)

HTH,

-Joe

>
> 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 
> <mailto: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>
>         <mailto: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 <tel:754%202008%206.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
>
>