[Cfp-interest 2091] Re: number classification macros, fpclassify and normal numbers

[Jim Thomas]

> On Aug 3, 2021, at 7:34 PM, Vincent Lefevre <vincent at vinc17.net> wrote:
> 
> It seems that the classification macros introduced in 7.12p12 of C2x
> N2596 (FP_INFINITE, FP_NAN, FP_NORMAL, FP_SUBNORMAL and FP_ZERO) are
> not explicitly defined. This may be obvious with the fpclassify
> description in 7.12.3.1p2, but it seems that "normal" has not been
> defined yet ("normalized" has been defined, but not "normal").
> 
> 7.12.3.6p2 says "The isnormal macro determines whether its argument
> value is normal (neither zero, subnormal, infinite, nor NaN)." but
> this does not constitute a definition (it is not in italic), and
> "neither zero, subnormal, infinite, nor NaN" excludes the possible
> implementation-defined categories allowed for fpclassify.

The classification macros were done thinking of IEC 60559, which uses the term “normal” and whose values classify as normal, zero subnormal, infinite, or NaN. 
> 
> Note that for a strict floating-point format, "normal" should be
> the same as "normalized”.

I think this would be a natural resolution, really just a clarification, and might (appear to) be the most helpful resolution for analysis. 

(1) We could say that FP_NORMAL applies to, and only to, normalized numbers. And, we would change the isnormal definition to say “normalized” instead of “normal”, and omit "(neither zero, subnormal, infinite, nor NaN)”.

Note that implementations can add their own classification macros FP_* for extensions to the FP model, like values in double-double format that have more or less precision than normalized values.

But ...

> But with values that are neither zero,
> subnormal, infinite, NaN, nor normalized, which may occur with the
> double-double format (conventional "long double" type on PowerPC),
> the meaning is ambiguous. Should the standard add some requirement,
> or should it make this implementation-defined?

Right. Question discussed below.

> 
> GCC assumes the following definition in gcc/builtins.c:
> 
>        /* isnormal(x) -> isgreaterequal(fabs(x),DBL_MIN) &
>           islessequal(fabs(x),DBL_MAX).  */
> 
> (for double; similar for the other types), where DBL_MIN is the
> minimum *normalized* positive floating-point number and DBL_MAX
> is the maximum representable finite number (see N2092[*]). Note:
> N2596 says "maximum representable finite floating-point number",
> but "floating-point" should be dropped to avoid ambiguity.
> 
> [*] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2092.htm
> 
> Thus for double-double, the only possibilities are zero, subnormal,
> normal, infinite and NaN. And a value may be classified as a normal
> number while not being a normalized floating-point number. Example:
> 1 + 2^(-200). It is not a normalized floating-point number because
> it does not fit in LDBL_MANT_DIG = 106 bits (as defined by GCC on
> PowerPC).

(2) We could say FP_NORMAL applies to normalized number and it is implementation defined whether it applies to other numbers (extensions to the floating-point model) with magnitude at least the minimum normalized number and at most the maximum finite number in the type.

Or 

(3) We could (as above) define the term “normal” to include all numbers with magnitude at least the minimum normalized number and at most the maximum finite number in the type. A footnote could say “normal” includes normalized numbers, and for IEC 60559 types normal and normalized are equivalent.

(3) seems the stronger, simpler approach, for dealing with formats like double-double. It doesn’t really make analysis more difficult for IEC 60559 formats because (the new) normal and normalized would be equivalent for them. Helping analysis for double-double seems too much to ask of these classification macros.

- Jim Thomas

> 
> -- 
> Vincent Lefèvre <vincent at vinc17.net> - Web: <https://www.vinc17.net/>
> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
> _______________________________________________
> Cfp-interest mailing list
> Cfp-interest at oakapple.net
> http://mailman.oakapple.net/mailman/listinfo/cfp-interest