Date:	Mon, 20 Mar 2000 17:37:00 +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.10003201423280.25247-100000@acp3bf>
Message-ID:	<Pine.SUN.3.91.1000320172540.26722B-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 Mon, 20 Mar 2000, Hans-Bernhard Broeker wrote:

> 'negative' is free for us to define, in the context of NaNs. 

Yes.  I suggest to define it as a "NaN", just like its brethren with
the sign bit reset.

> Actually, by our current 'printf("%+Lf", some_nan_with_sign_bit_set);
> outputting "-nan", we already have defined what 'negative' means,
> regarding NaNs, sort of.

That was a compromise.  We can either leave it or remove it.

> > > The result of nan(NULL) and/or nan("") should be some 'standard NaN', but
> > > I object to using the negative 'indefinite real' for that. Its positive
> > > (but nameless) counterpart would be a good choice.
> > 
> > That counterpart does have a name: it's a QNaN.  
> 
> No. QNaN is the name of the whole class of quiet NaNs. There are 2^62 of
> them with sign bit set, and another 2^62 with sign bit unset. Only one of
> them is the 'real indefinite', and only one other is identical to it with
> the exception that its sign bit is not set.

I fail to see the relevance of this.  You said that the real indefinite's 
counterpart without a sign has no name, to which I replied that it's name
is "QNaN".  How does it matter that there are many more QNaNs, in 
addition to this specific one?

> The problem with using real indefinite is what, AFAICS, strtod("nan") and
> strtod("-nan") are not supposed to give the same number.

If we define the sign of a NaN as not being significant, these two 
_could_ generate the same number.

> > > 	sprintf(buffer1, "%d", sqrt(-1));
> > > 	result = strtod(buffer1, NULL);
> > > 	sprintf(buffer2, "%d", result);
> > > 
> > > the two buffers contain identical strings.
> 
> > Anyway, I didn't check, but I won't be surprised if the above identity
> > is impossible to achieve: I'm afraid that the real indefinite doesn't
> > propagate intact through the computations.
> 
> There are no 'computations', in that example. the first printf() of
> sqrt(-1) yields a string. From there on, only conversion functions between
> character representation and binary floating point format are used.

Conversions inside strtod involve computations.  That's what I was 
referring to.  I don't think you can inject the real indefinite into the 
FPU and hope that it stays that way throught FP computations.  I assumed 
that some FP instructions would be used inside strtod, since FP values 
are returned in FP registers in our ABI.

- Raw text -