Value object equality & floating-point values

[John Rose]

+1; thanks Dan.  Value class authors can work with the tools we give them, if they prefer normal forms.  (And they will usually prefer to write their own .equals as well, although it’s not our place to force them to.)

On 13 Feb 2024, at 13:00, Dan Smith wrote:

> Another thing worth pointing out about field storage normalization: as it applies to the (value) class Double, it effectively deprecates the 'doubleToRawLongBits' method and implies that, from now on, in the boxed Double world, there's only one NaN.
>
> Stephen pointed out in valhalla-spec-observers that the factory method 'longBitsToDouble' turns out to allow for some amount of normalization—countering my claim that it must preserve all bits as provided. That is true, yet the Double API as a whole is clearly designed to support multiple NaNs. Without them, the introductory discussion about bit-wise vs. representational equivalence, and the distinction between 'doubleToLongBits' and 'doubleToRawLongBits', become moot.
>
> So the 'longBitsToDouble' specification may give us an opening to change the space of things encodable with Double, but I don't find much enthusiasm for taking advantage of that opening. An API that is fully conversant in the full 64 bits of the IEEE binary64 type seems like the right fit for the class Double.
>
> Then we can turn to other value classes that want to wrap 'double' fields. Some of them very well may want to normalize—and their authors are free to do so. Others might want to do encoding tricks with NaN, as far as the hardware allows. Yet others might opt for an integral type instead for their internal encoding (e.g., in my HalfFloat example above), and again these classes are free to normalize or not normalize in their own program logic.
>
> This leaves the platform itself to take a hands-off, least-common-denominator approach: bitwise equivalence, with classes responsible for managing their own bits and their own 'equals' relations.