Date:	Thu, 16 Mar 2000 19:22:43 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
cc:	djgpp workers list <djgpp-workers AT delorie DOT com>
Subject:	Re: Unnormals???
In-Reply-To:	<Pine.LNX.4.10.10003161706080.22148-100000@acp3bf>
Message-ID:	<Pine.SUN.3.91.1000316191037.6858B-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	dj-admin AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Thu, 16 Mar 2000, Hans-Bernhard Broeker wrote:

> > That's the crux of the problem: the Intel (probably also IEEE) definition 
> > of a NaN includes the sign bit set.  
> 
> Does it? My books both say that there are negative and positive NaNs, i.e.
> the sign bit of a NaN is treated exactly like in all other FP numbers.

Okay, my wording (and this whole discussion) was somewhat inaccurate, 
because apart of SNaNs and QNaNs, there's another beast involved here, 
which Intel calls ``real indefinite''.  This is a special NaN that is 
generated by the FPU as a masked response to an invalid operation 
exception.  This NaN has its sign bit set.

Naturally, most of the NaNs an average program will ever see are of this 
special kind.  So how we treat this NaN is very important.

So now, that we have introduced all of the different types of NaN, let me 
ask again: what shall we print for each and every type of them, with and 
without a sign, and what should nan() return?

> > So what would you suggest to be produced by nan()? Will the result have 
> > the sign bit set or not?  
> 
> A positive NaN, as nan(string) is supposed to behave exactly as
> strtod("NAN(string)"), i.e. there is no minus in front of it.

This is not an option if nan() produces the real indefinite.

> If the user wants a negative Nan, she should call strtod("-NAN") or
> strtod("-NAN(string)"), respectively. strtod() may calculate its result as
> -strtod("NAN)"), in turn, as far as C99 is concerned, but we could always
> choose the more sensible direct path, here, or at even set the sign bit by
> direct bit manipulation, instead of multiplying by -1.

The question is what we _should_ do, not what we _could_ do.  The 
standard is deliberately vague here (although less so than C89).

Don't forget that a NaN can be produced as sqrt(-1), for example.  Do we 
want that NaN be the same as what ``strtod("NaN")'' produces?

What the library currently does (and I'm not sure how consistently, but 
there is some consistency in it, as the Cygnus test suite demonstrates) 
is that it silently treats all NaNs the same, and treats the real 
indefinite as a negative NaN.  Does that comply to C99?  I don't know.

> > And how all of these cases will be printed by printf, with or without
> > the `+' in the format specifier?
> 
> Exactly like with non-special numbers. The decision regarding '+' or '-'
> sign output depends only on the sign bit of the number and the printf
> format options chosen (' ', '+' or none of them), really. I don't see any
> special treatment for NaN, Infinity or anything, here, neither in the
> C standard, nor in my x87 hardware book.

Would you like to reconsider this now, with the real indefinite being 
part of the picture?

- Raw text -