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

[Fred J. Tydeman]

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.

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

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

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

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


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