[Cfp-interest] Fwd: (SC22WG14.12761) Observations on N1631

[Jim Thomas]

Begin forwarded message:

> From: Jim Thomas <jaswthomas at sbcglobal.net>
> Subject: Re: (SC22WG14.12761) Observations on N1631
> Date: October 4, 2012 11:36:04 AM PDT
> To: Joseph S. Myers <jsm at polyomino.org.uk>
> Cc: sc22wg14 at open-std.org
> 
> Joseph, many thanks for finding these issues and reporting them so clearly. Please see below.
> 
> -Jim
> 
> On Oct 4, 2012, at 8:50 AM, Joseph S. Myers wrote:
> 
>> On Wed, 3 Oct 2012, Joseph S. Myers wrote:
>> 
>>>>> - 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?
>>> 
>>> What's missing is something saying "macro" alongside "function", so that 
>>> this is explicitly included in the recommended practice (and so included 
>>> in what must be implemented if FE_SNANS_ALWAYS_SIGNAL is defined).
>> 
>> Also: is raising the exception really the correct thing to do for 
>> *classification* macros?  They correspond to the non-computational 
>> operations listed in 754-2008 5.7.2 General operations - which says "They 
>> are never exceptional, even for signaling NaNs.".  So I'd have thought it 
>> would be a more accurate binding if the classification macros, old and new 
>> - and signbit, and the new totalorder functions, and copysign / fabs / 
>> negation as I mentioned earlier - were explicitly listed as not raising 
>> the exception for signaling NaNs (and then you could insert the word 
>> "macro" in the recommended practice, to make it explicit there what the 
>> *comparison* macros must do for signaling NaNs if FE_SNANS_ALWAYS_SIGNAL, 
>> with the other macros having been explicitly excluded individually).
> 
> You are right. 754-2008 is clear that its classification operations do not raise the "invalid" exception for signaling NaN arguments. We will look for appropriate changes in the spec.
> 
>> 
>> Notes:
>> 
>> * The binding of isZero to x == 0.0f, given in the table on page 8, is no 
>> longer a correct binding in the presence of signaling NaNs if == signals 
>> but isZero is non-computational and should not signal.
> 
> Looks like we need an iszero() macro. 
> 
>> 
>> * isnan (x) is no longer equivalent to isunordered (x, x) if isnan does 
>> not signal for signaling NaN input but isunordered does.  I don't think 
>> anything in the text suggests they are equivalent; this is more a note 
>> that could be relevant to C11 F.9.3, about a transformation 
>> implementations may currently do that isn't valid for signaling NaNs.
> 
> Right.
> 
>> 
>> -- 
>> Joseph S. Myers
>> joseph at codesourcery.com
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20121004/a53e7366/attachment.html