X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Martin Stromberg <eplmst AT epl DOT ericsson DOT se>
Message-Id: <200302271050.LAA12257@lws256.lu.erisoft.se>
Subject: Re: strtod.c: inf and nan support
To: djgpp-workers AT delorie DOT com
Date: Thu, 27 Feb 2003 11:50:33 +0100 (MET)
In-Reply-To: <3E5D44B8.B932A2EC@phekda.freeserve.co.uk> from "Richard Dawe" at Feb 26, 2003 10:50:32 PM
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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

Hi.

Richard said:
> ams AT ludd DOT luth DOT se wrote:
> > New file, djgpp/src/libc/c99/math/nan.c:
> > /* Copyright (C) 2003 DJ Delorie, see COPYING.DJ for details */
> > #include <libc/ieee.h>
> > 
> > float_t __dj_nan = { 0x7fffff, 0xff, 0x0 };

> > +#define NAN        __dj_nan

> What does isnan(NAN) give? Does this affect the results given by tests/cygnus
> at all?

Haven't tried (yet). But printf() prints it as "NaN" (unsure about
capitalisation).

> C99 says that NAN should be a quiet NaN.
> 
> "A quiet NaN propagates through almost every arithmetic operation without
> raising a floating-point exception; a signaling NaN generally raises a
> floating-point exception when occurring as an arithmetic operand."
> 
> Is NAN a quiet NaN? I don't know enough about floating-point to answer this
> question.

Of course. Some more quiet ones: { 0x5fffff, 0xff, 0x0 } and 
{ 0x400001, 0xff, 0x0 }.  Some signalling ones: { 0x3fffff, 0xff, 0x0 }, 
{ 0x1fffff, 0xff, 0x0 } and { 0x000001, 0xff, 0x0 }, It's the MSB in
the mantissa (of the fraction part) that differences them.


Some more questions: 
1. Should we support "nan(0x233)" to set specific bits in the NaN?
I'm willing to do the strto{d,f,ld}() parts, but not the *printf()
part.

2. If we do 1, we need to agree on the format. Mostly it's
straightforward, like a hexvalue of the pertinent bits, but for the
sign bit. "nan(-0x2323)", "nan(N0x2323)", "nan(1,0x2323)" and
"-nan(0x2323)" are some possibilities. Same question for the
Signalling bit if we want to support making a SNaN.

Am not sure 1 is worth to bother about for as soon as the value gets
into the FPU I suspect it might coerce the bits to some other NaN.


Right,

						MartinS