NaN

In computing, NaN (Not a Number) is a value of the numeric data type representing an undefined or unrepresentable value, especially in floating-point calculations. Systematic use of NaNs was introduced by the IEEE 754 floating-point standard in 1985, along with the representation of other non-finite quantities like infinities.

Two separate kinds of NaNs are provided, termed quiet NaNs and signaling NaNs. Quiet NaNs are used to propagate errors resulting from invalid operations or values, whereas signaling NaNs can support advanced features such as mixing numerical and symbolic computation or other extensions to basic floating-point arithmetic. For example, 0/0 is undefined as a real number, and so represented by NaN; the square root of a negative number is imaginary, and thus not representable as a real floating-point number, and so is represented by NaN; and NaNs may be used to represent missing values in computations.

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 might return an infinity) or an arithmetic underflow (which would return the smallest normal number, a denormal number, or zero).

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

For example, a bit-wise example of a IEEE floating-point standard single precision (32-bit) NaN would be: s111 1111 1axx xxxx xxxx xxxx xxxx xxxx where s is the sign (most often ignored in applications), a determines the type of NaN, and x is an extra payload (most often ignored in applications). If a = 1, it is a quiet NaN; if a is zero and the payload is nonzero, then it is a signaling NaN.

Floating point operations other than ordered comparisons normally propagate a quiet NaN (qNaN). Floating point operations on a signaling NaN (sNaN) signal an 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.

A comparison with a NaN always returns an unordered result even when comparing with itself. The comparison predicates are either signaling or non-signaling, the signaling versions signal an invalid exception for such comparisons. The equality and inequality predicates are non-signaling so x = x returning false can be used to test if x is a quiet NaN. The other standard comparison predicates are all signaling if they receive a NaN operand, the standard also provides non-signaling versions of these other predicates. The predicate isNaN(x) determines if a value is a NaN and never signals an exception, even if x is a signaling NaN.

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.

In the revised IEEE 754-2008 standard there are a few anomalous functions (such as the maxnum function, which returns the maximum of two operands that are expected to be numbers) that favor numbers — if just one of the operands is a NaN then the value of the other operand is returned.

The NaN 'toolbox' for GNU Octave and MATLAB goes one step further and skips all NaNs when computing aggregates (like sums, products, averages or standard deviations). NaNs are assumed to represent missing values and so the statistical functions ignore NaNs in the data instead of propagating them. Every computation in the NaN toolbox is based on the non-NaN data only.

Creation
There are three kinds of operations that can return NaN:


 * Operations with a NaN as at least one operand.
 * Indeterminate forms
 * The divisions 0/0 and ±∞/±∞
 * The multiplications 0×±∞ and ±∞×0
 * The additions ∞ + (−∞), (−∞) + ∞ and equivalent subtractions
 * The standard has alternative functions for powers:
 * The standard pow function and the integer exponent pown function define 00, 1∞, and ∞0 as 1.
 * The powr function defines all three indeterminate forms as invalid operations and so returns NaN.


 * Real operations with complex results, for example:
 * The square root of a negative number.
 * The logarithm of a negative number
 * The inverse sine or cosine of a number that is less than −1 or greater than +1.

NaNs may also be explicitly assigned to variables, typically as a representation for missing values. Prior to the IEEE standard, programmers often used a special value (such as −99999999) to represent undefined or missing values, but there was no guarantee that they would be handled consistently or correctly.

NaNs are not necessarily generated in all the above cases. If an operation can produce an exception condition and the exception is not masked then the operation will cause an exception instead. If an operand is a quiet NaN, and there isn't also a signalling NaN operand, then there is no exception condition and the result is a quiet NaN. Explicit assignments will not cause an exception even for signalling NaNs.

Quiet NaN
Quiet NaNs, or qNaNs, do not raise any additional exceptions as they propagate through most operations. The exceptions are where the NaN cannot simply be passed through unchanged to the output, such as in format conversions or certain comparison operations (which do not "expect" a NaN input).

Signaling NaN
Signaling NaNs, or sNaNs, are special forms of a NaN that when consumed by most operations should raise an invalid 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:

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. There are other approaches to this sort of problem that would be more portable.
 * Filling uninitialized memory with signaling NaNs would produce an invalid 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

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 is that if the function has multiple arguments and the output is uniquely determined by all the non-NaN inputs, then that value should be the result.

The problem is particularly acute for the exponentiation function pow(x,y) = x ** y. Both 00 and 1∞ are considered indeterminate forms when they occur as limits (just like also ∞ × 0, which also has an indeterminate sign and an indeterminate value bound), and the question of whether zero to the zero power should be defined as 1 has divided opinion.

If the output is considered as undefined if a parameter is undefined then pow(1,qNaN) should produce a qNaN. However typically math libraries have returned 1 since pow(1, y) = 1 for any real number y, and they return 1 even if y is infinity or -infinity. Similarly they produce 1 for pow(qNaN,0). The 2008 version of the IEEE 754 standard says should be done. The rationale is that the value of functions at singular points can be taken as a particular value if that value is in the limit the value for all but a vanishingly small part of a ball around the parameters.

To satisfy those wishing a more strict interpretation as in the first view the standard defines two additional power functions; pown(x, n) where the exponent must be an integer, and powr(x, y) which returns a NaN whenever a parameter is a NaN or the exponentiation would give an indeterminate form.

Integer NaN
Most fixed sized integer formats do not have any way of explicitly indicating invalid data.

Perl's BigInt package uses "NaN" for the result of strings that don't represent valid integers.

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

nan NaN NaN% NAN NaNQ NaNS qNaN sNaN 1.#SNAN 1.#QNAN -1.#IND

Since, in practice, encoded NaNs have both a sign and optional 'diagnostic information' (sometimes called a payload), these will often be found in string representations of NaNs, too, for example:

-NaN NaN12345 -sNaN12300 -NaN(s1234)

(other variants exist)

Encoding
In IEEE 754 standard-conforming floating point storage formats, NaNs are identified by specific, pre-defined bit patterns unique to NaNs and that cannot be inadvertently mistaken for regular (defined and representable) floating point values.
 * In all four binary formats (binary16, binary32, binary64, binary128), NaNs are identified by
 * 1) an exponent field in which all bits are non-zero (like the storage format for ±infinity) and
 * 2) a fraction field in which at least one bit is non-zero (unlike the storage format for ±infinity).
 * In practice, signaled/quiet state is represented in the first bit following the sign and exponent fields. (on both big- and little-endian systems, this is the most significant bit in the fraction field). The exact interpretation of that bit varies (see below). When the quiet/signaling bit is clear at least one other bit in the fraction field will/must be set to ensure that the encoding for NaNs is distinguishable from the encoding for ±infinity.


 * In all three decimal formats (decimal32, decimal64, decimal128), NaNs are identified by
 * 1) five non-zero bits following the sign bit.
 * Signaled/quiet state is represented in the sixth bit following the sign bit.

These patterns are independent of precision. They are also used in non-standard but IEEE 754-like floating point formats such as Intel's/Motorola's 80bit "extended precision" or 8bit "minifloats".

The original IEEE 754 standard from 1985 (IEEE 754-1985) did not specify how the signaled/quiet state was to be tagged. Two different implementations, with reversed meanings, resulted.
 * most processors (including those of the Intel/AMD x86-32/x86-64 family, the Motorola 68000 family, the AIM PowerPC family, the ARM family, and the Sun SPARC family) set the signaled/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 MIPS processors, the signaled/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 2008 revision of the IEEE 754 standard (IEEE 754-2008) makes formal recommendations for the interpretation of the signaled/quiet bit.
 * For binary formats, the standard follows the interpretation as an 'is_quiet' flag. I.e. the signaled/quiet bit is non-zero if the NaN is quiet, and zero if the NaN is signaling. The standard still allows implementations to use several bits to distinguish signaling and quiet NaNs.
 * For decimal formats, the standard follows the interpretation as an 'is_signaling' flag. I.e. the signaled/quiet bit is zero if the NaN is quiet, and non-zero if the NaN is signaling.

The state/value of the remaining bits (i.e. other than the ones used to identify a NaN as NaN, including the quiet/signaled bits) are not defined by the standard.