Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!ucsd!hub!dougp
From: dougp@voodoo.ucsb.edu
Newsgroups: comp.lang.c
Subject: Re: Not A Number in IEEE Math
Message-ID: <4030@hub.UUCP>
Date: 22 Feb 90 05:23:00 GMT
Sender: news@hub.UUCP
Organization: UC, Santa Barbara. Physics Computer Services
Lines: 27

-Message-Text-Follows-
In article <10515@alice.UUCP>, ark@alice.UUCP (Andrew Koenig) writes...
>	0.0 * infinity = NaN (+ or - infinity -- I think it's implementation
>		defined whether or not NaN has a sign)
>	0.0 * NaN = NaN (as mentioned before)
>	0.0 * anything else = 0.0
> 
>	NaN / NaN = NaN (as mentioned before)
> 
>	infinity / infinity = NaN
>	infinity / NaN = Nan (as mentioned before)
>	infinity / anything else = infinity

Does this mean that compilers arn't alowed to optimize code?

Suppose someone writes:

double a,b;
a=NaN; /* who cares how*/
b=NaN;

a/a==1 /*can the compiler optomize this to TRUE ?*/
a/b!=1 /*this should work out to TRUE*/
0*a    /*can the compiler optomize this to 0? */

In most cases you never run into NaNs, I think I would prefer to
have the compiler optomize a/a to 1 and 0*a to zero.