NaN

Floating point

In floating-point calculations, NaN is not the same as infinity, although both are typically handled as special cases in floating-point representations of real numbers as well as in floating-point operations. An invalid operation is also not the same as an arithmetic overflow (which would return an infinity or the largest finite number in magnitude) or an arithmetic underflow (which would return the smallest normal number in magnitude, a subnormal number, or zero).

In the IEEE 754 binary interchange formats, NaNs are encoded with the exponent field filled with ones (like infinity values), and some non-zero number in the trailing significand field (to make them distinct from infinity values); this allows the definition of multiple distinct NaN values, depending on which bits are set in the trailing significand field, but also on the value of the leading sign bit (but applications are not required to provide distinct semantics for those distinct NaN values).

For example, an IEEE 754 single precision (32-bit) NaN would be encoded as

where s is the sign (most often ignored in applications) and the x sequence represents a non-zero number (the value zero encodes infinities). In practice, the most significant bit from x is used to determine the type of NaN: "quiet NaN" or "signaling NaN" (see details in Encoding). The remaining bits encode a payload (most often ignored in applications).

Floating-point operations other than ordered comparisons normally propagate a quiet NaN (qNaN). Most floating-point operations on a signaling NaN (sNaN) signal the invalid-operation exception; the default exception action is then the same as for qNaN operands and they produce a qNaN if producing a floating-point result.

The propagation of quiet NaNs through arithmetic operations allows errors to be detected at the end of a sequence of operations without extensive testing during intermediate stages. For example, if one starts with a NaN and adds 1 five times in a row, each addition results in a NaN, but there is no need to check each calculation because one can just note that the final result is NaN. However, depending on the language and the function, NaNs can silently be removed from a chain of calculations where one calculation in the chain would give a constant result for all other floating-point values. For example, the calculation x0 may produce the result 1, even where x is NaN, so checking only the final result would obscure the fact that a calculation before the x0 resulted in a NaN. In general, then, a later test for a set invalid flag is needed to detect all cases where NaNs are introduced (see Function definition below for further details).

Comparison with NaN

Comparisons are specified by the IEEE 754 standard to take into account possible NaN operands. When comparing two real numbers, or extended real numbers (as in the IEEE 754 floating-point formats), the first number may be either less than, equal to, or greater than the second number. This gives three possible relations. But when at least one operand of a comparison is NaN, this trichotomy does not apply, and a fourth relation is needed: unordered. In particular, two NaN values compare as unordered, not as equal.

As specified, the predicates associated with the

<

{\displaystyle <}

,

≤

{\displaystyle \leq }

,

=

{\displaystyle =}

,

≥

{\displaystyle \geq }

,

>

{\displaystyle >}

mathematical symbols (or equivalent notation in programming languages) return false on an unordered relation. So, for instance, NOT

(

x

<

y

)

{\displaystyle (x<y)}

is not logically equivalent to

Operations generating NaN

There are three kinds of operations that can return NaN:

Most operations with at least one NaN operand.

Indeterminate forms:

The divisions

(

±

0

)

/

(

±

0

)

{\displaystyle (\pm 0)/(\pm 0)}

and

(

±

∞

)

/

(

±

∞

)

{\displaystyle (\pm \infty )/(\pm \infty )}

.

The multiplications

(

±

0

)

×

(

Quiet NaN

In general, quiet NaNs, or qNaNs, do not raise any additional exceptions, as they propagate through most operations. But the invalid-operation exception is signaled by some operations that do not return a floating-point value, such as format conversions or certain comparison operations.

Signaling NaN

Signaling NaNs, or sNaNs, are special forms of a NaN that, when consumed by most operations, should raise the invalid operation exception and then, if appropriate, be "quieted" into a qNaN that may then propagate. They were introduced in IEEE 754. There have been several ideas for how these might be used:

Filling uninitialized memory with signaling NaNs would produce the invalid operation exception if the data is used before it is initialized

Using an sNaN as a placeholder for a more complicated object, such as:

A representation of a number that has underflowed

A representation of a number that has overflowed

Number in a higher precision format

A complex number

When encountered, a trap handler could decode the sNaN and return an index to the computed result. In practice, this approach is faced with many complications. The treatment of the sign bit of NaNs for some simple operations (such as absolute value) is different from that for arithmetic operations. Traps are not required by the standard.

Payload operations

IEEE 754-2019 recommends the operations getPayload, setPayload, and setPayloadSignaling be implemented, standardizing the access to payloads to streamline application use. According to the IEEE 754-2019 background document, this recommendation should be interpreted as "required for new implementations, with reservation for backward compatibility".

Encoding

In IEEE 754 interchange formats, NaNs are identified by specific, pre-defined bit patterns unique to NaNs. The sign bit does not matter. For the binary formats, NaNs are represented with the exponent field filled with ones (like infinity values), and some non-zero number in the trailing significand field (to make them distinct from infinity values). The original IEEE 754 standard from 1985 (IEEE 754-1985) only described binary floating-point formats, and did not specify how the signaling/quiet state was to be tagged. In practice, the most significant bit of the trailing significand field determined whether a NaN is signaling or quiet. Two different implementations, with reversed meanings, resulted:

most processors (including those of the Intel and AMD's x86 family, the Motorola 68000 family, the AIM PowerPC family, the ARM family, the Sun SPARC family, and optionally new MIPS processors) set the signaling/quiet bit to non-zero if the NaN is quiet, and to zero if the NaN is signaling. Thus, on these processors, the bit represents an is_quiet flag;

in NaNs generated by the PA-RISC and old MIPS processors, the signaling/quiet bit is zero if the NaN is quiet, and non-zero if the NaN is signaling. Thus, on these processors, the bit represents an is_signaling flag.

The former choice has been preferred as it allows the implementation to quiet a signaling NaN by just setting the signaling/quiet bit to 1. The reverse is not possible with the latter choice because setting the signaling/quiet bit to 0 could yield an infinity.

The 2008 and 2019 revisions of the IEEE 754 standard make formal requirements and recommendations for the encoding of the signaling/quiet state.

For binary interchange formats, the most significant bit of the trailing significand field is exclusively used to distinguish between quiet and signaling NaNs. (This requirement has been added in the 2019 revision.) Moreover, it should be an is_quiet flag. That is, this bit is non-zero if the NaN is quiet, and zero if the NaN is signaling.

For decimal interchange formats, whether binary or decimal encoded, a NaN is identified by having the top five bits of the combination field after the sign bit set to ones. The sixth bit of the field is the is_signaling flag. That is, this bit is zero if the NaN is quiet, and non-zero if the NaN is signaling.

Canonical NaN

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). ARM can enable a "default NaN" mode for this behavior. WebAssembly has the same behavior, though it allows two canonical values.

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. Java has the same treatment "for the most part".

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. (This concept of "canonical NaN" is not the same as the concept of a "canonical encoding" in IEEE 754.)

Function definition

There are differences of opinion about the proper definition for the result of a numeric function that receives a quiet NaN as input. One view is that the NaN should propagate to the output of the function in all cases to propagate the indication of an error. Another view, and the one taken by the ISO C99 and IEEE 754-2008 standards in general, is that if the function has multiple arguments and the output is uniquely determined by all the non-NaN inputs (including infinity), then that value should be the result. Thus for example the value returned by hypot(±∞, qNaN) and hypot(qNaN, ±∞) is

+

∞

{\displaystyle +\infty }

.

The problem is particularly acute for the exponentiation function pow(x, y) =

x

y

{\displaystyle x^{y}}

. The expressions

0

0

{\displaystyle 0^{0}}

,

∞

0

{\displaystyle \infty ^{0}}

and

1

∞

{\displaystyle 1^{\infty }}

are considered indeterminate forms when they occur as limits (just like

∞

Integer NaN

Most fixed-size integer formats cannot explicitly indicate invalid data. In such a case, when converting NaN to an integer type, the IEEE 754 standard requires that the invalid-operation exception be signaled.

For example in Java, such operations throw java.lang.ArithmeticException.

In C, they lead to undefined behavior, but if annex F is supported, the operation yields an "invalid" floating-point exception (as required by the IEEE standard) and an unspecified value.

In the R language, the minimal signed value (i.e. 0x80000000) of integers is reserved for NA (Not available). Conversions from NaN (or double NA) to integers then yield a NA integer.

Perl's Math::BigInt package uses "NaN" for the result of strings that do not represent valid integers.

Display

Different operating systems and programming languages may have different string representations of NaN.

nan (C, C++, Python, Zig)

NaN (ECMAScript, Rust, C#, Julia, Java). Julia may show alternative NaN, depending on precision, NaN32, and NaN16; NaN is for Float64 type.

NaN%

NAN (C, C++, Rust)

NaNQ (IBM XL and AIX: Fortran, C++ proposal n2290)

NaNS (ditto)

qNaN

sNaN

1.#SNAN (Excel)

1.#QNAN (Excel)

-1.#IND (Excel)

+nan.0 (Scheme)

Since, in practice, encoded NaNs have a sign, a quiet/signaling bit and optional 'diagnostic information' (sometimes called a payload), these will occasionally be found in string representations of NaNs, too. Some examples are:

For the C and C++ languages, the sign bit is always shown by the standard-library functions (e.g. -nan) when present. There is no standard display of the payload nor of the signaling status, but a quiet NaN value of a specific payload may either be constructed by providing the string nan(char-sequence) to a number-parsing function (e.g. strtod) or by providing the char-sequence string to nan() (or nans() for sNaN), both interpreted in an implementation-defined manner.

GCC and LLVM provide built-in implementations of nan() and nans(). They parse the char-sequence as an integer for strtoull (or a differently sized equivalent) with its detection of integer bases.