[Cfp-interest 2030] Re: FLT_HAS_SUBNORM is 0: what is fpclassify(<subnormal>)?

[Jim Thomas]

Thoughts about this thread …

If subnormal encodings are really treated as non-canonical zeros, then they actually are zeros. This implies reasonable behavior for the operations in Fred’s lists, and FLT_HAS_SUBNORM should be 0. The flush-to-zero HW modes might be helpful in implementing this model, but the implementation would need to be careful to get all the details right.

IEC 60559 specifies the alternate exception handling attribute, abruptUnderflow, which is supported in IEC 18661-5 (but it is not in the C Standard). Under this attribute, operations signaling underflow return zeros or minimal-magnitude normal numbers of the same sign, depending on the rounding direction. Subnormal operands are not treated as zeros. Results are not affected unless underflow is signaled. This too implies reasonable behavior for the operations in Fred’s list. If this were the implementation’s default mode, then FLT_HAS_SUBNORM arguably should be 1.

C 5.2.4.2.2 specifies FLT_HAS_SUBNORMAL to be

−1 	indeterminable27)
0 	absent (type does not support subnormal numbers)28)
1 	present (type does support subnormal numbers)

27)Characterization as indeterminable is intended if floating-point operations do not consistently interpret subnormal representations as zero, nor as nonzero.
28)Characterization as absent is intended if no floating-point operations produce subnormal results from non-subnormal inputs, even if the type format includes representations of subnormal numbers.

Footnote 28 seems problematic. It means (if the  characterization is “absent”) that if a program does not explicitly create subnormals, then the arithmetic does not produce any. But it allows representations of subnormal numbers and doesn’t say anything about how they are handled. Note that the footnote does not apply to abruptUnderflow, because, for example, nextup(0) which does not signal underflow is unaffected by abruptUnderflow and yields a subnormal result.

- Jim Thomas


> On Jun 16, 2021, at 9:19 AM, Steve (Numerics) Canon <scanon at apple.com> wrote:
> 
>> On Jun 15, 2021, at 8:44 PM, David Hough CFP <pcfp at oakapple.net> wrote:
>> 
>>> I do not know if a negative subnormal would be flushed to -zero or +zero.
>> 
>> Signs were preserved on the systems I knew about.
>> 
>>> This matters for (at least):
>> fpclassify()
>> iscanonical()
>> issubnormal()
>> iszero()
>> signbit()
>> nextafter()
>> nexttoward()
>> nextup()
>> nextdown()
>> 
>> I'd suggest that these kinds of functions ignore the flush mode and 
>> identify subnormals properly - the actual arithmetic would do whatever it
>> did in nonstandard mode.
> 
> There definitely exists some hardware that flushes all subnormals to +0, but it is a distinct minority (at least for CPUs, which generally preserve sign when flushing). Preserving the sign seems like the “obvious” correct choice, but not all HW has done that.
> 
> AFAIK no standard offers any real guidance on how to handle the operations Fred listed. I disagree mildly with David, however, and would argue that if you want to have a consistent semantics for flush-to-zero, the only really defensible choice is to treat all subnormals as non-canonical encodings of zero, because that’s how they behave in arithmetic. This is how Swift resolved this question when targeting ARMv7 platforms that always flush, for example (which happily are mostly behind us now).
> 
> – Steve
> _______________________________________________
> Cfp-interest mailing list
> Cfp-interest at oakapple.net <mailto:Cfp-interest at oakapple.net>
> http://mailman.oakapple.net/mailman/listinfo/cfp-interest <http://mailman.oakapple.net/mailman/listinfo/cfp-interest>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20210621/18201566/attachment.htm>