# Does anybody anywhere care about NaN payloads?

**URL:** <https://discourse.julialang.org/t/does-anybody-anywhere-care-about-nan-payloads/94152>\
**Category:** General Usage\
**Tags:** nan\
**Created:** [February 6, 2023, 5:15pm UTC](https://discourse.julialang.org/t/does-anybody-anywhere-care-about-nan-payloads/94152 "2023-02-06T17:15:55Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Lilith](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lilith/32/27492_2.png) [@Lilith](https://discourse.julialang.org/u/Lilith)\
**Post date:** [February 6, 2023, 5:15pm UTC](https://discourse.julialang.org/t/does-anybody-anywhere-care-about-nan-payloads/94152/1 "2023-02-06T17:15:55Z")

</div>

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](https://github.com/JuliaLang/julia/issues/48523) 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?

---

<div class="post-metadata">

**Author:** ![quinnj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/quinnj/32/11_2.png) [@quinnj](https://discourse.julialang.org/u/quinnj)\
**Post date:** [February 6, 2023, 6:02pm UTC](https://discourse.julialang.org/t/does-anybody-anywhere-care-about-nan-payloads/94152/2 "2023-02-06T18:02:46Z")

</div>

As I mentioned [here](https://github.com/JuliaLang/julia/issues/48523#issuecomment-1419509901), in SentinelArrays.jl, we’re explicitly relying on the `0xffffffffffffffff` NaN payload to be “reserved” to SentinelArrays.jl.

---

<div class="post-metadata">

**Author:** ![mikmoore](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mikmoore/32/31109_2.png) [@mikmoore](https://discourse.julialang.org/u/mikmoore)\
**Post date:** [February 6, 2023, 7:21pm UTC](https://discourse.julialang.org/t/does-anybody-anywhere-care-about-nan-payloads/94152/3 "2023-02-06T19:21:05Z")

</div>

> [@Lilith](#):
>
> For example, `min(NaN, anotherNaN)` might return `NaN` on one operating system but `anotherNaN` on another.

This is already true except that it’s by hardware. As of [#41709](https://github.com/JuliaLang/julia/pull/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?”](https://grouper.ieee.org/groups/msc/ANSI_IEEE-Std-754-2019/background/nan-propagation.pdf)). 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](https://github.com/JuliaLang/julia/pull/47814), `min` uses a native instruction on `aarch64` which likely has a different selection criterion. If I ever finish [#45581](https://github.com/JuliaLang/julia/pull/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).