Date: Thu, 16 Mar 2000 15:51:45 -0600
From: Eric Rudd <rudd AT cyberoptics DOT com>
Subject: Re: Unnormals???
To: djgpp-workers AT delorie DOT com
Message-id: <38D15771.85A4776@cyberoptics.com>
Organization: CyberOptics
MIME-version: 1.0
X-Mailer: Mozilla 4.72 [en] (Win95; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
References: <Pine DOT LNX DOT 4 DOT 10 DOT 10003161829580 DOT 22148-100000 AT acp3bf>
Reply-To: djgpp-workers AT delorie DOT com

Hans-Bernhard Broeker wrote:

> Well, if Intel decided that the 'standard' NaN was to be negative, then so be
> it.

For "real indefinite", the sign bit is set.  However, I'd rather not call it
"negative", since, for NaNs, the sign bit doesn't really signify anything about
the numerical value (indeed, NaN *has* no numerical value), and since the sign bit
of NaN does not obey the usual arithmetic laws when it is used in floating-point
arithmetic.

The NaN without the sign bit set is a "signaling NaN".  According to Intel:

     QNaNs are allowed to propagate through most arithmetic operations
     without signaling an exception.  SNaNs generally signal an
     invalid-operation exception whenever they appear as operands in
     arithmetic operations.

If we call "real indefinite" -NaN, then we have

-NaN * SNaN => SNaN
SNaN * SNaN => SNaN
-NaN * -NaN => -NaN

> They probably only chose it because of the 'nice' binary form: a
> series of 1 bits, then a series of 0 bits. I see no reason not to print it
> as negative, except for the a bit of irritation to some readers of the
> output.

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.

-Eric Rudd
rudd AT cyberoptics DOT com