Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!ibmpa!slo!jsalter
From: jsalter@slo.uucp (James Salter)
Newsgroups: comp.lang.c
Subject: Re: Not A Number in IEEE Math
Keywords: IEEE floating point
Message-ID: <4294@ibmpa.UUCP>
Date: 28 Feb 90 18:05:56 GMT
References: <44@newave.UUCP> <14266@s.ms.uky.edu>
Sender: news@ibmpa.UUCP
Reply-To: jsalter@slo.UUCP (James Salter)
Organization: IBM AWD, Palo Alto
Lines: 33

In article <14266@s.ms.uky.edu> simon@ms.uky.edu (G. Simon Gales) writes:
>I think that that behavior is correct.  
>
[... 0.0 ...]
>	NaN / NaN = 1.0
>
>Also a NaN/NaN situation is usually treated as 1, but this is definitely
>not intended to be a -correct- result.  If you end up with NaNs in your
>computation's results, you can't trust the answers you get.

No.  It is *explicitly* stated in IEEE 854, Sec. 6.2, Paragraph 4 (or so)

	"Every operation involving one or two input NaNs, ..., if a
	floating-point result is to be delivered, shall deliver as its result
	a quiet NaN, which should be one of the input NaNs."

where "operation" above is defined (5.1):

	"An implementation shall provide the add, subtract, multiply, divide
	and remainder operations for any two operands ..."

Thus, NaN/NaN != 1.0; in fact, it *can* not be a representable floating
point number.  It is NaNQ (maybe with an exception thrown in if one of
the NaNs is signalling).

If you want a controversy, ask about pow(0.0,0.0), but NaN behavior is
specified quite completely.

>Simon Gales@The University of Kentucky

jim/jsalter   IBM AWD   T465/(415)855-4427    VNET: JSALTER at PALOALTO
UUCP: ..!uunet!ibmsupt!jsalter               Disc: Any opinions are mine.
IP: ibmsupt!jsalter@uunet.uu.net                 "PS/2 it, or DIE!"