[Cfp-interest] NaN - Background paper

[Jim Thomas]

Good background info. A few comments below.

-Jim

>This paper compares what 754-2008 recommends regarding NaNs and what
>C99 (or draft C1x) and the C decimal FP Technical Report already
>provide. It also suggests ways to enhance C to better align with
>754-2008 in this area.  In the following, 'DFP' means the WG14 (C
>Standards) Decimal Floating-Point Technical Report.
>
>IEEE 2.1.40 payload: The diagnostic information contained in a NaN,
>encoded in part of its trailing significand field.  
>
>C99 makes no mention of such diagnostic information in NaNs.
>
>
>IEEE 3.2 Specification levels
>Multiple NaN bit strings should be used to store retrospective
>diagnostic information (see 6.2).
>
>C99 makes no mention of such diagnostic information in NaNs.
>
>
>IEEE 3.3 Sets of floating-point data
>Within each format, the following floating-point data shall be
>represented:
> -- Two NaNs, qNaN (quiet) and sNaN (signaling).
>
>C99 has: quiet NAN of type float.
>DFP has: quiet DEC_NAN of type _Decimal32.
>Signaling NaN (sNaN) is missing from both.
>

IEEE 3.3 is referring to the format representations, not how those format representations can be designated in the language.

>
>IEEE 3.4 Binary interchange format encodings
>a) ..., then r is qNaN or sNaN and v is NaN regardless of S (see
>6.2.1).
>
>C99 makes no mention of encodings.

Annex F says types float and double use IEEE formats. Encoding is as aspect of those formats.

>
>IEEE 3.5.2 Encodings
>a) ..., then v is NaN regardless of S.  Furthermore, if G5 is 1, then
>r is sNaN; otherwise r is qNaN. ... and T constitutes the NaN's
>payload, which can be used to distinguish various NaNs. A NaN is in
>its preferred (canonical) representation if the bits ... are zero and
>the encoding of the payload is canonical.
>
>The bit pattern in a NaN trailing significand field can affect how the
>NaN is propagated (see 6.2).
>
>DFP makes no mention of encodings or payloads.


Whether and how C might address decimal encodings is a separate topic, not specific to NaNs. The Functions subgroup will need to deal with the decimal reencoding functions.


>
>IEEE 5.3.1 General operations
>minNum is fmin in C99 and qNaN treatment is specified the same.
>maxNum is fmax in C99 and qNaN treatment is specified the same.

Note that IEEE requires these functions to treat sNaNs and qNaNs differently, in return value as well as exceptions.

>IEEE 5.3.2 quantize
>quantize is quantize in DFP and qNaN treatment is specified the same.
>
>IEEE 5.3.3 logBFormat operations
>floating logB is logb in C99 and qNaN treatment is specified the same.
>integer logB is ilogb in C99; ilogb(NaN) is FP_ILOGBNAN [which is either
>INT_MAX or INT_MIN].  Unfortunately, if 'int' is 16-bits and long
>double has a 15-bit (or bigger) exponent, then ilogb(NaN) will not be
>outside +/-2 * (emax + p -1) as specified by IEEE.
>
>IEEE 5.5.1 Sign bit operations
>copy is = in C99 and qNaN treatment is not specified.  But,
>copysign(x,x) is also copy(x) and qNaN treatment is specified the
>same.
>
>negate is unary - in C99 and qNaN treatment is not specified.  But,
>copysign(x,signbit(x)?+1.0:-1.0) is negate(x) and qNaN treatment is
>specified the same.


F.3 is intended to bind unary – to the IEEE standard.


>abs is fabs in C99 and qNaN treatment is not specified.  

F.9 says fabs of a qNaN is a qNaN.

>But,
>copysign(x,1.0) is also abs(x) and qNaN treatment is specified the same.
>
>
>IEEE 5.7.2 General operations
>If C were to support signaling NaNs, passing a sNaN to a function
>might (or might not) trigger the sNaN and turn it into a qNaN before
>the function gets control.  Hence, there is no way for these functions
>to always be unexceptional.
>
>class is classify in C99 and qNaN treatment is specified the same.
>However, sNaN is treated as qNaN in C99.
>
>isSignMinus is signbit in C99 and qNaN treatment is specified the
>same.
>
>isNormal is isnormal in C99 and qNaN treatment is specified the same.
>
>isFinite is isfinite in C99 and qNaN treatment is specified the same.
>
>isNaN is isnan in C99 and qNaN treatment is specified the same.
>
>isSignaling is missing from C99.
>
>isCanonical is missing from C99.
>
>
>IEEE 5.7.3 sameQuantum
>sameQuantum is samequantum in DFP and qNaN treatment is specified the
>same.
>
>IEEE 5.8 Details of conversions from floating-point to integer formats.
>qNaN treatment is specified the same (C99 F.4).
>
>IEEE 5.9 Details of operations to round a FP datum to integral value
>sNaN is not supported in C (if it were, C's treatment would match IEEE)
>
>IEEE 5.10 Details of totalOrder predicate
>Missing from C99.
>
>IEEE 5.11 Details of comparison predicates
>C99 has both quiet [is* macros] and signaling [<,<=,>=,>] predicates
>as per IEEE and NaN is unordered.
>
>IEEE 5.12.1 discusses I/O of NaNs.  
>C99 meets the "shall" requirements for qNaNs (but not sNaNs).  There
>is no way to force the printing of a NaN payload (but that is only a
>"should" in IEEE).  However, strto* functions will process a NaN
>payload 

... assuming there’s a mapping between payloads and n-char-sequences

>
>(but what they do with it is implementation defined).
>
>
>IEEE 6.2 Operations with NaNs.
>Most of the "shall" requirements are at the "hardware" level -- which
>C99 annex F assumes is done correctly.  But, C99 has no support for
>sNaN.
>
>IEEE 6.2.3 mentions language-defined diagnostic information (as a
>"should").  C99 has no such requirement, but does have a recommended
>practice that matches IEEE.
>
>IEEE 6.2.3 NaN propagation mentions I/O (see 5.12.1).
>
>C99 Annex F meets the requirements on qNaNs for +, -, *, /, <, <=, ==,
>!=, >, >=, =, (cast), implicit conversions, is* comparison macros,
>sqrt().
>
>IEEE 7.2 Invalid operation
>For operations producing results in floating-point format, the default
>result of an operation that signals the invalid operation exception
>shall be a quiet NaN that should provide some diagnostic information
>(see 6.2).  C99 annex F adopts that behavior (but makes no mention of
>the diagnostic information).  C99 appears to be missing ilogb(NaN)
>raise invalid.

 Yikes.

>IEEE 9. Recommended operations
>IEEE 9.1.1 Exceptions
>All functions shall return a quiet NaN as a result if there is a NaN
>among a function's operands, except in the cases listed in 9.2.  C99
>annex F qNaN treatment is specified the same.
>
>Attempts to evaluate a function outside its domain shall return a
>quiet NaN and signal the invalid operation exception.  C99 annex F is
>specified the same (on a function by function basis).
>
>IEEE 9.2.1 Special values
>hypot(+/-INF,qNaN) is +INF and hypot(qNaN,+/-INF) is +INF.  C99 annex
>F has the same requirement.
>
>pow(qNaN,+/-0.) is 1.  C99 annex F is the same.
>pow(1.,qNaN) is 1.  C99 annex F is the same.
>
>IEEE Annex B Program debugging support
>Outside the scope of C99.
>
>Summary.
>
>As far as I can tell, C99 meets almost all the "shall" requirements on
>qNaNs of IEEE-754.  But, C99 has no support for sNaNs of IEEE-754.
>Points of failure:
>  ilogb(NaN) -- no invalid
>  ilogb(NaN) -- not outside IEEE's range if 'int' is 16-bits.
>Points needing improvement:
>  copy/=
>  negate/-
>  abs/fabs
>  printing of NaN payload
>
>Comments from previous discussions:
> What should be done with SNaNs?
>   SNaNs should go away = 754r wish; only done for backward compatibility
>     Raise invalid and become qNaN is only portable thing can do with them.
>   Could be used for uninitialized memory (but only if all 1s pattern
>     is an SNaN (for union of float/double/long double)) -- which is
>     not a requirement of IEEE.
>   Could be used for "extensions" -- but only if have signal handlers
>     for invalid (which is an extension beyond C99).  Also, those
>     signal handlers need some way to "return" (also an extension
>     beyond C99).  Those signal handlers probably need some way to
>     provide a result in place of the sNaN (again, an extension beyond
>     C99).
>
> Need to have input NaN propage to output result (to track history);
>   but that requirement is a "should", not a "shall" in IEEE-754 (6.2.3).
>   It is a recommended practice for the C99 <math.h> functions.
>
> What happens when a decimal FP sNaN is converted to binary FP?
>   IEEE 754 6.2, 3rd paragraph makes it clear that invalid is
>   signaled. 7.2 makes it clear that a qNaN is the result.



Fred J. Tydeman wrote:

>I have posted a background paper on NaNs on the wiki
>in the NaNs area.  Comments welcome.
>
>---
>Fred J. Tydeman        Tydeman Consulting
>tydeman at tybor.com      Testing, numerics, programming
>+1 (775) 358-9748      Vice-chair of PL22.11 (ANSI "C")
>Sample C99+FPCE tests: http://www.tybor.com
>Savers sleep well, investors eat well, spenders work forever.
>
>_______________________________________________
>Cfp-interest mailing list
>Cfp-interest at oakapple.net
>http://mailman.oakapple.net/mailman/listinfo/cfp-interest
>
>
>  
>