Editing NaN (section)

=== Canonical NaN ===
{{Confusing|1=section|reason=IEEE 754 already uses "canonical NaN" with the meaning of "canonical encoding of a NaN" (e.g. "isCanonical(x) is true if and only if x is a finite number, infinity, or NaN that is canonical." page 38, but also for totalOrder page 42), thus a different meaning from what is used here|date=February 2024}}
A number of systems have the concept of a "canonical NaN", where one specific NaN value is chosen to be the only possible qNaN generated by floating-point operations not having a NaN input. The value is usually chosen to be a quiet NaN with an all-zero payload and an arbitrarily-defined sign bit.
* On RISC-V, most floating-point operations only ever generate the canonical NaN, even if a NaN is given as the operand (the payload is not propagated).<ref>{{cite web |last1=Embeddev |first1=Five |title="F" Standard Extension for Single-Precision Floating-Point, Version 2.2 / RISC-V Instruction Set Manual, Volume I: RISC-V User-Level ISA |url=https://five-embeddev.com/riscv-isa-manual/latest/f.html#sec:single-float |website=Five EmbedDev}}</ref>{{efn|IEEE 754-2008 recommends, but does not require, propagation of the NaN payload. Most processors choose to obey this recommendation, but do not by themselves generate a non-zero payload.<ref>{{unbulleted list citebundle|1={{cite web |last1=Fog |first1=Agner |title=NaN payload propagation - unresolved issues |url=https://grouper.ieee.org/groups/msc/ANSI_IEEE-Std-754-2019/background/nan-propagation.pdf |date=2018-04-11}}|2={{cite web |last1=Fog Agner |title=Floating point exception tracking and NAN propagation |url=https://www.agner.org/optimize/nan_propagation.pdf |date=2020-04-27}}}}</ref> The RISC-V behavior is thus non-recommended but compliant.}} ARM can enable a "default NaN" mode for this behavior.<ref>{{cite web |title=NaN handling and the Default NaN (ARM Architecture Reference Manual ARMv7-A and ARMv7-R edition) |url=https://developer.arm.com/documentation/ddi0406/c/Application-Level-Architecture/Application-Level-Programmers--Model/Floating-point-data-types-and-arithmetic/NaN-handling-and-the-Default-NaN |website=Documentation – Arm Developer}}</ref> WebAssembly has the same behavior, though it allows two canonical values.<ref name=wasm>{{cite web |title=What is the motivation for 'NaN' canonicalization? · Issue #1463 · WebAssembly/design |url=https://github.com/WebAssembly/design/issues/1463 |website=GitHub |language=en}} &ndash; see response by Dan Gohman "sunfishcode"</ref>
* A number of languages do not distinguish among different NaN values, without requiring their implementations to force a certain NaN value. ECMAScript (JavaScript) code treats all NaN as if they are the same value.<ref name=ecma262>{{cite web |title=ECMAScript® 2026 Language Specification - 6.1.6.1 The Number Type |url=https://tc39.es/ecma262/multipage/ecmascript-data-types-and-values.html#sec-ecmascript-language-types-number-type |website=tc39.es |quote=In some implementations, external code might be able to detect a difference between various NaN values, but such behaviour is implementation-defined; to ECMAScript code, all NaN values are indistinguishable from each other. |language=en}}</ref> Java has the same treatment "for the most part".<ref>{{cite web |title=Chapter 4. Types, Values, and Variables |url=https://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.2.3 |website=docs.oracle.com |quote=For the most part, the Java SE platform treats NaN values of a given type as though collapsed into a single canonical value, and hence this specification normally refers to an arbitrary NaN as though to a canonical value.}}</ref>

Using a limited amount of NaN representations allows the system to use other possible NaN values for non-arithmetic purposes, the most important being "NaN-boxing", i.e. using the payload for arbitrary data.<ref>{{cite book |last1=Nystrom |first1=Robert |title=Crafting Interpreters |date=28 July 2021 |publisher=Genever Benning |isbn=978-0-9905829-3-9 |url=https://craftinginterpreters.com/optimization.html#nan-boxing|chapter=&sect; 30.3 NaN Boxing |language=English}}</ref> (This concept of "canonical NaN" is not the same as the concept of a "canonical encoding" in IEEE 754.)