Value object equality & floating-point values

[Joseph D. Darcy]

Catching up on email...

On 2/13/2024 1:09 PM, Dan Smith wrote:
>> On Feb 12, 2024, at 6:54 PM, Joe Darcy <joe.darcy at oracle.com> wrote:
>>>
>>> To put it simply, the spec *already allows* normalization (for the
>>> very good reason that no Java developer should ever be exposed to
>>> different NaNs).
>> The origin of that paragraph stems from idiosyncrasies of  64-bit double support on the x87 FPU -- tl;dr a format changing load/store instruction rather than a move instruction had to be used to get values on and off the floating-point stack. Fortunately, JEP 306: "Restore Always-Strict Floating-Point Semantics" removed most such issues from a spec perspective, which had not been a serious concern from an implementation perspective for some time.
> Joe, does this imply that primitive floating-point data movement *in general* may not preserve NaN bits? E.g., the following assert may fail?
>
> value class C {
>      double d;
>      C(double d) { this.d = d; }
>
>      static double TMP;
> }
>
> double d1 = ...;
> C.TMP = d1;
> double d2 = C.TMP;
> C c1 = new C(d1);
> C c2 = new C(d2);
> assert c1 == c2; // bitwise equivalence test


On current architectures, that should work, but the test matrix should 
include a variety of platform-specific signaling NaN values. (Signaling 
NaNs are a feature of IEEE 754 outside of the computation model of the 
Java language and JVM.)

HTH,

-Joe