The value of floatToRawIntBits(0.0f/0.0f) is different on x86_64 and aarch64?

[Joe Darcy]

Hello,

Adding a bit more background below...

On 7/15/2019 12:10 AM, Aleksey Shipilev wrote:
> On 7/15/19 8:46 AM, Aleksey Shipilev wrote:
>> On 7/15/19 6:05 AM, Tianhua huang wrote:
>>> The value of floatToRawIntBits(0.0f/0.0f) is different on x86_64 and
>>> aarch64? Does it depends on the platform? I think the behaviour should be
>>> same on different platforms, right?
>> Why should it be? 0.0f/0.0f is NaN. There are multiple allowed representations of NaN in IEEE-754.
>> And there is a difference about "raw" conversions:
>>
>> "If the argument is NaN, the result is the integer representing the actual NaN value. Unlike the
>> floatToIntBits method, floatToRawIntBits does not collapse all the bit patterns encoding a NaN to a
>> single "canonical" NaN value."
>>   (https://docs.oracle.com/javase/8/docs/api/java/lang/Float.html#floatToRawIntBits-float-)
>>

As Aleksey notes, the IEEE 754 standard defines many possible bit 
strings to encode NaN values. Additionally, the default NaN bit pattern 
for a freshly created NaN is not specified by the standard and is 
platform-dependent and does indeed vary by platform. Additionally, the 
floating-point standard and at least its 2008 revision do not specify 
the bits of the NaN output if an operation has multiple NaN inputs.

The intention of this design of NaN handling was to allow flexibility 
for "retrospective diagnostic" debugging features to be developed, which 
did not occur very much.

(And I won't even go into the platform-specific differences between 
quiet NaNs and signaling NaNs, differences not exposed by the Java 
platform.)

When it comes to reproducing the raw *bits* of floating-point results, 
the Java platform is not necessarily reproducible because the underlying 
standard allows implementation variation. When it comes to reproducing 
the *values* of floating-point results, the Java platform is 
reproducible (subject to a complicated disclaimer about over/underflow 
and non-strict floating-point).

For reproducability, Float.floatToIntBits has an internal NaN-check and 
returns a canonical NaN bit pattern. For seeing if two floating-point 
values x and y are semantically equivalent

     Double.compare(x, y) == 0

will do a sensible comparison.

I don't see any JDK bug here and the platform provides the necessarily 
primitives to do reproducible comparison of floating-point values.

HTH,

-Joe