Does anybody anywhere care about NaN payloads?

General Usage
1

There are a bunch of different NaN values. NaN and anotherNaN = reinterpret(Float64, reinterpret(UInt64, NaN) + 1) and NaN are two examples. There is a proposal to explicitly disclaim any garuntees about which NaN you receive. For example, min(NaN, anotherNaN) might return NaN on one operating system but anotherNaN on another. Would that inconvenience anyone?

2

As I mentioned here, in SentinelArrays.jl, we’re explicitly relying on the 0xffffffffffffffff NaN payload to be “reserved” to SentinelArrays.jl.

3 Likes
3

This is already true except that it’s by hardware. As of #41709, the current implementation of min(a,b) returns a-b when either argument is NaN. But the result of a-b when both arguments are NaN is hardware dependent (for example, see this document, the section “What should happen when two payloads are combined?”). In some related cases (but likely not this one), it could even vary arbitrarily during compilation. For example, the document claims that a compiler will sometimes interchange a+b and b+a, even though the resulting NaN can be different when both arguments are NaN).

EDIT:
And as of #47814, min uses a native instruction on aarch64 which likely has a different selection criterion. If I ever finish #45581, then the reduction version minimum will have even different semantics that are deterministic across systems (except that aarch64 would likely opt-out in favor of #47814).

1 Like