Value object equality & floating-point values

[forax at univ-mlv.fr]

----- Original Message -----
> From: "John Rose" <john.r.rose at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "daniel smith" <daniel.smith at oracle.com>, "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Sent: Tuesday, February 13, 2024 10:18:24 PM
> Subject: Re: Value object equality & floating-point values

> On 9 Feb 2024, at 12:32, forax at univ-mlv.fr wrote:
> 
>>
>> We fix == but for NaN looks like a terrible slogan.
> 
> 
> There’s no question of fixing anything.  Actually, float== (fcmp/dcmp) is
> permanently broken for NaN.  It’s the inevitable consequence of having Java
> import IEEE 754.  You already teach your students that, surely.
> 
> We aren’t trying to fix ==.  We are steering towards a semantics for values
> which is compatible with ref== (acmp) today.  And that is substitutability, in
> all its details, including the unwelcome details.  Two objects which store
> distinguishable NaNs are distinct, hence not the same, and hence not ref==.
> (Whether they are float== is a very different matter.)

I believe that fixing == in case of *boxing* is achievable.

I teach my students the difference between == and Double.equals(), and why both exist.

The main problem I see with value types and == being the bitwise equivalence is that wrapper types will now mostly works with ==

Because the case where does not work is a corner case of a corner case, you need NaN that are not Double.NaN, students will never see the issue.
If an issue is not easily reproductible, it's hard to convince students that the issue exist (we have the same problem with teaching the difference between the different hardware memory models).

> 
> We are not trying to align ref== with float==, because that is an impossible
> goal.
> 
> We could try to file off an unimportant rough edge by making some NaNs less
> distinct from each other, by normalizing NaNs stored in some fields in some
> classes.  (All value classes fields is the proposal of the week.)  That won’t
> change the result of float== on such values; they are still never float==,
> whether distinct or not.

If think that normalizing NaNs is an operation users code can do, and maybe something we will have to teach students if == on value types uses bitwise equivalence.
But it's not something the execution model should do, at least not only for value classes. If agree with you on that.

That does not change the fact that == on value classes can be the representational equivalence instead of the bitwise equivalence.
It's what Double.equals()/Float.equals() do.

BTW, i've never heard someone complaining that Double.equals()/Float.equals() should not do NaN normalization for performance reason.

Rémi