[Cfp-interest 1748] Re: Underflow range error

[Jim Thomas]

> On Aug 11, 2020, at 2:07 PM, Fred J. Tydeman <tydeman at tybor.com> wrote:
> 
> Attached is my first pass at words for the C standard about
> exact subnormal results and three math functions.
> 
> 
> ---
> Fred J. Tydeman        Tydeman Consulting
> tydeman at tybor.com <mailto:tydeman at tybor.com>      Testing, numerics, programming
> +1 (702) 608-6093      Vice-chair of PL22.11 (ANSI "C")
> Sample C99+FPCE tests: http://www.tybor.com <http://www.tybor.com/>
> Savers sleep well, investors eat well, spenders work forever.
> 
> 
> Submitter:CFP group
> Submission Date: 2020-??-??
> Document: WG14 N25??
> Title: N25??: Exact subnormal results
> Reference Documents:N2506
> 
> Summary
> 
> This is a follow on to N2506 that was accepted (except for three math functions). Those three functions [fmod(), remainder(), and remquo()] can produce exact subnormal results and there was a question on should they underflow.
> 
> 7.12.1 Treatment of error conditions has two "requirements" related to this issue.
> 
> #4 has:
> 
> Likewise, a range error occurs if and only if the mathematical result of the function cannot be represented in an object of the specified type, due to extreme magnitude.
> #6 has:
> 
> The result underflows if the magnitude of the mathematical result is nonzero and less than the minimum normal number in the type.243)
The idea here was to give an inclusive definition — in particular, to include IEC 60559 exact underflow. In IEC 60559, tininess is an underflow condition, whether or not the result is exact. The exact underflow case does not cause the underflow flag to be raised, but is detectable with some methods of alternate exception handling (as in TS5).
> So, if an exact subnormal result is produced, is it an underflow range error?
> 
> 
This case is intended to be, and is according to the definition in #6, an underflow. 
> Since it is exact, it is representable, so does not meet the condition in paragraph 4.
> 
Right. We might consider loosening #4 so that it includes underflow (per #6).  For example,

[4] Likewise, a range error occurs if the mathematical result is beyond the range where all values can be represented in an object of the specified type, to the full precision of the type.

Or, we might explicitly regard exact underflow to be a range error condition. For example, add after the first sentence in #6

… Then a range error occurs, even if the value can be exactly represented in the specified type. ...

Neither of these changes would break implementations because they don’t narrow the cases of underflow range errors and it’s up to the implementation whether to indicate (by errno or flag) whether on underflow occurred.

I like the idea of loosening #4. The alternative seems like a work around.

> Since it is subnormal, it meets the condition of paragraph 6.
> 
> So what is it?
> 
> Assuming exact subnormal results are not underflow, here are proposed wording changes to the C standard.
> 
> C2x changes:
> 
> 7.12.1 Treatment of error conditions
> Add to 7.12.1#6 after the first sentance.
> 
> If the result is exactly representable, it is implementation defined if an underflow happens. Footnote
> Footnote: Alternate exception handling (not part of Standard C) is one way that an exact subnormal result is an underflow.
> 
Isn’t the problem that with the current definitions underflow isn’t a range error condition? Having the implementation call exact underflow an underflow doesn’t make it a range error (per #4). 

- Jim Thomas
> The fmod functions
> Add to 7.12.10.1#2
> 
> A range error may occur if x is finite, both x and y are nonzero, and either is too close to zero.
> The remainder functions
> Add to 7.12.10.2#2
> 
> A range error may occur if x is finite, both x and y are nonzero, and either is too close to zero.
> The fdim functions
> Change 7.12.12.1#2
> 
> A range error may occur.
> to:
> 
> A range error may occur if positive finite x-y is too close to zero. A range error occurs if positive finite x-y is too large.
> _______________________________________________
> 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/20200814/a8b0715a/attachment-0001.htm>