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.da...@oracle.com
<mailto:joe.da...@oracle.com>> wrote:
On 8/20/2016 3:16 PM, Martin Buchholz wrote:
On Sat, Aug 20, 2016 at 12:32 PM, Martin Buchholz
<marti...@google.com <mailto:marti...@google.com>
<mailto:marti...@google.com <mailto:marti...@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
