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

[Jim Thomas]

On Jan 10, 2012, at 10:37 AM, Fred J. Tydeman wrote:

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

That helps. Do you think all the exceptions required in Annex F would be allowed if we defined exceptions to be errors as you suggest?

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

The trap handler wouldn't be useful for handling signaling NaNs if couldn't 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.

I'd rather not have minor aspects of ilogb and llogb be specified differently, especially since this difference wouldn't matter to Annex F implementations. I'll add an issue for it.

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

Right. But they'd have to change so that math_errhandling & MATH_ERRNO would not be non zero, which could break forward compatibility.

-JIm

> 
>>> 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.
> 
> _______________________________________________
> Cfp-interest mailing list
> Cfp-interest at oakapple.net
> http://mailman.oakapple.net/mailman/listinfo/cfp-interest