Value object equality & floating-point values

[Stephen Colebourne]

On Mon, 12 Feb 2024 at 21:16, Dan Smith <daniel.smith at oracle.com> wrote:
> Stephen Colebourne suggested a normalization approach to floating-point field storage:
>
> >> * For each `float` or `double` field in a value class, the constructor
> >> will generate normalization code
> >> * The normalization is equivalent to `longBitsToDouble(doubleToLongBits(field))`
> >> * Normalization also applies to java.lang.Float and java.lang.Double
> >> * == is a Bitwise implementation, but behaves like Representational
> >> for developers
>
> The Oracle-internal discussion last spring covered similar ground. There are different ways to stack it, but what they have in common is an interest in eradicating NaN encoding variations as some sort of unwanted anomaly. I get that this is often the case (for the tiny fraction of programmers who ever encounter NaN in the first place). But let's not overlook the fact that, since 1.3, there's an API that explicitly supports these encodings and promises to preserve them (Double.doubleToRawLongBits and Double.longBitsToDouble). Note that Double is a value class that wraps a field of type 'double'. Flattening out NaN encoding differences in the wrapped field would break that API.

This claim doesn't stand up to scrutiny I'm afraid.

longBitsToDouble() says this:
"Note that this method may not be able to return a double NaN with
exactly same bit pattern as the long argument"
https://docs.oracle.com/javase/8/docs/api/java/lang/Double.html#longBitsToDouble-long-
The whole paragraph is a vital read for anyone following this thread.

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).

I'm really serious about this topic - because the proposed solution is
simply not appropriate for Java as a blue collar language.

Stephen