[Cfp-interest] review draft for CFP TS Part 1 content

[Fred J. Tydeman]

On Mon, 9 Jan 2012 11:15:47 -0800 Jim Thomas wrote:
>
>> We could add words to F.10 Mathematics <math.h>
>> 
>> "Invalid" is a domain error.
>> "Divide-by-zero" is a pole error.
>> "Overflow" and "underflow" are range errors.
>
>This might could go after F.10 #9, as a way of tying floating-point exceptions 
>to the error specification in 7.12. But that doesn't mean we should start 
>specifying domain and range errors in Annex F. Another concern is that currently 
>a requirement for an error is satisfied by an appropriate exception (assuming 
>math_errhandling & MATH_ERREXCEPT is non zero), but, I believe, an exception is 
>not necessarily an error, which allows Annex F to specify exceptions even where 
>domain/pole/range errors are not allowed by 7.12 (e.g., see ilogb).

I disagree with the 'not allowed' in above.  C11, 7.12.1#2 has:

The description of each function lists any required domain errors; 
an implementation may define additional domain errors, provided
that such errors are consistent with the mathematical definition 
of the function.231)

>>> Should signaling NaNs cause errno to be set? If so then we probably want to 
>>> say so in the main library clause.
>> 
>> If a signaling NaN survives the calling convention and the function
>> sees it, then we have a domain error.  
>
>Maybe. I guess it's neater if all invalid exceptions are domain errors. On the 
>other hand, the invalid exception raised from a signaling NaN may be viewed as 
>a way of invoking a trap handler to get special semantics - not an error at all.

I believe that viewpoint assumes that invalid from signaling NaN is different
than all other invalids.  And that a trap handler could tell the difference.

>>>> 7.12.6.7 The llogb functions
>>>> Add at end of description:  and a domain error occurs.
>>> 
>>> The llogb words are the same as for ilogb. Do you think ilogb is wrong?
>> 
>> Yes, I think ilogb is wrong.  It (and llogb) should say:
>> A domain error occurs if x is zero, infinite, or NaN.
>> If the correct value is outside the range of the return type,
>> a domain error occurs and the numeric result is unspecified.
>
>I recall that the C committee considered this and was willing to have the 
>specification (for out-of-range cases) only in Annex F, not in clause 7.12. 
>Since the current spec is fine for Annex F implementations, 
>I don't think the CFP TS is the right vehicle for re-raising the issue.  

OK.  But, I would like to see llogb have all errors (including out of range) 
be domain errors.  That matches lrint and lround.

>>> Do narrowing add, sub, mul, and div need to set errno? Setting errno would 
>>> have a major performance cost on implementations with HW instructions that can 
>>> deliver narrower results. The corresponding built-in operators don't set 
>>> errno.
>> 
>> errno should be set if the expression 
>> math_errhandling & MATH_ERRNO is nonzero.
>> 
>> So, each implementation determines what is best for its customers.
>> If they have HW instructions, then they should set math_errhandling
>> to the value MATH_ERREXCEPT.
>
>Unfortunately, implementations have to continue supporting errno for legacy reasons.

Those implementations could define math_errhandling as just MATH_ERREXCEPT.
And, they could also set errno (as per 7.12.1#7) for the existing legacy
reasons, but not set errno for new functions.

>> We could add words to F.10 Mathematics <math.h>
>> 
>> "Invalid" is a domain error.
>> "Divide-by-zero" is a pole error.
>> "Overflow" and "underflow" are range errors.
>
>That would mean every FP exception required by Annex F would have to be 
>allowed in 7.12. How close does 7.12 come to this? 

I believe that 7.12 matches Annex F in almost every case.
ilogb is the one exception that I know of (which does not match lrint, 
nor lround, which require an error for out of range results).

---
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.