Date: Sun, 19 Mar 2000 11:54:57 +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 AT delorie DOT com
Subject: Re: Unnormals???
In-Reply-To: <Pine.LNX.4.10.10003171254580.23502-100000@acp3bf>
Message-ID: <Pine.SUN.3.91.1000319115441.13844V-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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
Precedence: bulk


On Fri, 17 Mar 2000, Hans-Bernhard Broeker wrote:

> > If we call "real indefinite" -NaN, then we have
> > 
> > -NaN * SNaN => SNaN
> > SNaN * SNaN => SNaN
> > -NaN * -NaN => -NaN
> 
> The first two will actually yield QNaN, as we mask invalid operation
> exceptions, which causes the FPU to automatically convert any SNaN to a
> QNaN, and go on.
> 
> The third one is where the trouble lies: I have no documentation about
> what happens to the sign bits of operands in such operation with
> NaN, it seems. Anyone?

I think it will produce a QNaN as well.  The Intel manual explicitly
says that the real indefinite is only produced when *none* of the
operands is a NaN (neither QNaN nor SNaN).  When both operands are
QNaNs, as in our case, the result is a QNaN.  It certainly cannot be
an SNaN, since SNaNs are *never* generated by the FPU, they can only
be forcibly loaded into the FPU by a program.

However, Intel manuals are not known for 100% accuracy, especially
when the FPU is concerned, so testing this in an actual program cannot
possibly hurt...

Btw, it seems that Intel clearly treats the real indefinite as a QNaN,
its sign is only an indication that it was generated from finite
operands.  IMHO this is one more argument to the effect that it's not
a real sign, just a flag.

> > I would vote for suppressing the sign of NaN except when it is
> > explicitly specified in a format specifier (as is currently done)
> > since, as I argue above, "real indefinite" is not really negative.
> 
> The C99 explicitly mentions signs of NaNs in its output specification for
> *printf(), and also in strtod()/*scanf() input. I don't think we can just
> say the a NaN with the sign bit set is *not* negative.

I think we can, since the sign bit of a NaN is not an indication of
it's being negative, when the real indefinite is concerned.