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

Mon Jan 9 11:15:47 PST 2012

On Jan 9, 2012, at 9:14 AM, Fred J. Tydeman wrote:

> On Sun, 8 Jan 2012 21:11:09 -0800 Jim Thomas wrote:
>> 
>> Thanks, Fred, Below are some shoot-from-the-hip comments. More generally, are 
>> we agreed that we should use C11 as a model for how to specify errors for the 
>> new functions we add?
> 
> C11's 7.12.1 Treatment of error conditions
> seems fine with me (along with each function mentioning domain, pole, and/or
> range errors).  This avoids mention of errno in each function.
> 
>> On Jan 8, 2012, at 4:08 PM, Fred J. Tydeman wrote:
>> 
>>> On Wed, 4 Jan 2012 16:23:02 -0800 Jim Thomas wrote:
>>>> 
>>>> The errno requirements are not in yet. Fred, would you be
>>>> willing to list the errno changes you think are needed?
>>> 
>>> F.2.1 Infinities and NaNs
>>> Recommended practice
>>> Add at end of 1st paragraph: (and for functions, shall be a domain
>>> error).
>> 
>> There's currently nothing in Annex F about domain or range errors (as you note 
>> regarding the last item below).
> 
> 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).

> 
>> The recommended practice applies to built-in operations as well as library 
>> functions. Built-in operations don't set errno.
> 
> That is why only functions get a domain error.

Sorry, I missed that.

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

> Whether errno gets set to EDOM
> depends upon math_errhandling.
> 
>>> 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.  

> 
>>> 7.12.14.1 Add and round to narrower type
>>> Add at end of description:  for finite arguments.  A domain error may
>>> occur for infinite arguments.
>> 
>> How about range errors? Likewise for the other narrowing functions below.
> 
> You misread my edit.  

I did.

> The new words are:
> A range error may occur for finite arguments.  A domain error may
> occur for infinite arguments.
> 
>> 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.

> 
>> The current fma spec just says "A range error may occur." 
> 
> That should be changed to:
> A range error may occur for finite arguments.  A domain error may
> occur for infinite arguments.
> 
>>> 7.12.14.2 Subtract and round to narrower type
>>> Add at end of description:  for finite arguments.  A domain error may
>>> occur for infinite arguments.
>>> 
>>> 7.12.14.3 Multiply and round to narrower type
>>> Add at end of description:  for finite arguments.  A domain error
>>> occurs for one infinite argument and one zero argument.
>>> 
>>> 7.12.14.4 Divide and round to narrower type
>>> Add at end of description:  for finite arguments.  A domain error
>>> occurs for either both arguments infinite or both arguments zero.  A
>>> pole error occurs for a finite x and a zero y.
>>> 
>>> 7.12.14.5 Floating multiply-add and round to narrower type
>>> Add at end of description:  for finite arguments.  A domain error
>>> may occur for an infinite argument.
>>> 
>>> 7.12.14.6 Square root and round to narrower type
>>> Add at end of description: for finite positive arguments.  A domain
>>> error occurs for negative arguments.
>>> 
>>> F.10.8.5 The canonicalize functions
>>> ISSUE:  SNaN => domain error?  No where else in Annex F is domain
>>> error mentioned.  
>> 
>> Right.
>> 
>>> But, if math errors are reported via both flags and
>>> errno, then error shall be set to EDOM.
>> 
>> Please say more.
> 
> How errors are reported is determined by: math_errhandling
> as detailed in C11 7.12.1 Treatment of error conditions.
> 
> F.10#4: The expression math_errhandling & MATH_ERREXCEPT shall evaluate to a
> nonzero value.
> 
> 7.12.1#7: If a domain, pole, or range error occurs and the integer expression
> math_errhandling & MATH_ERRNO is zero,233) then errno shall either be set to
> the value corresponding to the error or left unmodified. If no such error occurs, errno
> shall be left unmodified regardless of the setting of math_errhandling.
> 
> So, Annex F requires that errors be reported via the FP flags.
> It is up to the implementation if errors will also be reported
> via errno.
> 
> 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? 

-Jim 

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