[Cfp-interest 1832] Re: pow() and signaling NaN

Jim Thomas jaswthomas at sbcglobal.net
Thu Oct 29 17:24:56 PDT 2020



> On Oct 29, 2020, at 3:12 PM, Damian McGuckin <damianm at esi.com.au> wrote:
> 
> On Thu, 29 Oct 2020, Jim Thomas wrote:
> 
>> F.2.1 #3 says ?? This annex uses the term NaN, unless explicitly qualified, to denote quiet NaN ??.
> 
> I see a "twin question mark" symbol in your email Jim. I assume it is really a double quote symbol.

Yes, double quote.
> 
> Anyway, is this not different from the IEEE 754? At least as I read the standard, the term NaN with lower case 'a' means either qNaN or sNaN.

It’s a different editorial approach.

> 
> It does match the symbolic constant NAN which is always a quiet NaN. 

In C, NAN is a macro. Yes, it expands to something representing a quiet NaN. 

> 
> Do we have to use language which is that much different from the IEEE 754 (IEC 60559) standard or is there too much history behind its usage in the C standard that it is too hard to change?

Background: Till now, signaling NaNs have not been supported in standard C, and NaNs were taken to be quiet NaNs. In TS 18661-1 (now in draft C23) we tried to clean up the specification so that a conforming C implementation could support signaling NaNs as specified in IEEE 754. This involved clarifying which type of NaN was being referred to in each case. For Annex F, the editorial decision was to have the general statement in F.2.1 #3 noted above, rather than qualify all the instances of “NAN”. Given that users should be able to ignore signaling NaNs, and almost all do ignore them, or try to. IEEE 754 works perfectly well without signaling NaNs. Note that it does not distinguish signaling NaNs at Level 2 in the table of specification levels (3.2). It seemed better not to force the C user to consider them any more than is necessary for correctness of the spec.

I believe what you’re asking is if we could explicitly say “quiet NaN” wherever we now say “NaN’ under the scope of the general statement in F.2.1 #3. If CFP wants to pursue this, someone could go through Annex F and list where the changes would need to occur.

- Jim Thomas

> 
> Regards - Damian
> 
> Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
> Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
> Views & opinions here are mine and not those of any past or present employer




More information about the Cfp-interest mailing list