[Cfp-interest] (SC22WG14.12733) Observations on N1631

[Jim Thomas]

Fix noted below is in the draft posted today.

-Jim

On Sep 30, 2012, at 3:15 PM, Jim Thomas wrote:

> 
> 
> Begin forwarded message:
> 
>> From: Jim Thomas <jaswthomas at sbcglobal.net>
>> Subject: Re: (SC22WG14.12733) Observations on N1631
>> Date: September 30, 2012 3:14:33 PM PDT
>> To: Joseph S. Myers <jsm at polyomino.org.uk>
>> Cc: sc22wg14 at open-std.org
>> 
>> 
>> Joseph,
>> 
>> Thanks for the further comments. Please see responses below.
>> 
>> -Jim
>> 
>> On Sep 27, 2012, at 5:45 PM, Joseph S. Myers wrote:
>> 
>>> Some more observations, these ones relating to signaling NaNs, and cases 
>>> where C11 specifies something in math.h as a macro rather than a function:
>>> 
>>> * The recommended practice for signaling NaNs (page 18, lines 4-5) is that 
>>> "[6] Any floating-point operator or <math.h> function with a signaling NaN 
>>> input, unless explicitly specified otherwise, raises an "invalid" 
>>> floating-point exception.".  This raises a couple of questions:
>>> 
>>> - Is it also recommended practice for comparison and classification 
>>>   *macros* to raise that exception for signaling NaNs, unless specified 
>>>   otherwise?  If so, should that be stated explicitly, so it's part of 
>>>   the recommended practice included in the FE_SNANS_ALWAYS_SIGNAL 
>>>   semantics?
>> 
>> Yes, the recommended practice applies to the comparison and classification macros. The new issignaling macro explicitly states that it determines its result "without raising a floating-point exception". Other classification macros should, according to the recommended practice, raise the "invalid" floating-point exception if an argument is a signaling NaN. So should the comparison macros. Suggested changes to the descriptions of the comparison macros in 7.12.14 are intended to admit the recommended practice (but not require it). Is there something we're missing?
>> 
>>> 
>>> - Does this recommended practice include recommending that negation, 
>>>   fabs and copysign raise that exception for signaling NaNs?  (Those 
>>>   being quiet-computational operations in 754-2008, I'm not sure what 
>>>   the intent of 754-2008 is regarding what they do with signaling NaNs - 
>>>   5.5.1 says "signal no exception", unconditionally, but 6.2 refers to 
>>>   "Every general-computational and quiet-computational operation 
>>>   involving one or more input NaNs, *none of them signaling* ..." (my 
>>>   emphasis).)
>> 
>> The intention in 754-2008 and the CFP spec is that these operations raise no floating-point exceptions, even if the input is a signaling NaN. 754-2008 clearly states this in 5.5.1, and doesn't contradict itself in 6.2 (although 6.2 could have been more definitive). However, I don't see were C11 or the CFP spec says this, except by reference to 754. We'll look into it.

I haven't added anything here yet. The binding table refers to the IEC 60559 spec which says these operations "signal no exception". We might still want to put something in the draft.

>> 
>>> 
>>> * The iseqsig macro is specified to produce a domain error for NaN 
>>> arguments.  Is this meant to require setting errno if math_errhandling & 
>>> MATH_ERRNO is nonzero - or not, because the wording about what domain 
>>> errors mean (C11 7.12.1 paragraph 2) is only for functions, not macros?
>> 
>> Maybe we could say directly (without reference to domain errors) that errno is set to EDOM if math_errhandling & MATH_ERRNO is nonzero and an argument is a NaN.

Fixed by saying a domain error occurs as though for a function.

>> 
>>> 
>>> -- 
>>> Joseph S. Myers
>>> joseph at codesourcery.com
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20121003/476f1dce/attachment-0001.html