Date: Tue, 18 Mar 2003 19:31:15 +0200
From: "Eli Zaretskii" <eliz AT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: rudd AT cyberoptics DOT com
Message-Id: <9743-Tue18Mar2003193115+0200-eliz@elta.co.il>
X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 1.8.9
CC: djgpp-workers AT delorie DOT com
In-reply-to: <3E7736C6.5040903@cyberoptics.com> (message from Eric Rudd on
	Tue, 18 Mar 2003 09:09:58 -0600)
Subject: Re: isnan and isinf
References: <200303181210 DOT NAA03843 AT lws256 DOT lu DOT erisoft DOT se> <3E7736C6 DOT 5040903 AT cyberoptics DOT com>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> Date: Tue, 18 Mar 2003 09:09:58 -0600
> From: Eric Rudd <rudd AT cyberoptics DOT com>
> 
> The question also came up about which flavors of NaN to recognize.  In 
> normal FPU computation, the only type of NaN that occurs is the "real 
> indefinite" non-signalling NaN, which you get, for instance, by 
> computing 0./0.  I think that the penalty for recognizing all the 
> flavors is that you have to test both upper and lower longwords, rather 
> than just the most-significant longword.  I decided that the extra 
> effort wasn't justified for the libc math routines, since the other NaNs 
> aren't supposed to occur anyway, but maybe we want to put the extra code 
> into an explicit function like isnan().

Yes, I think `isnan' should support all flavors of NaNs, especially if
we add to `strtod' and friends the ability to produce a NaN with a
specific bit pattern.