X-Authentication-Warning: acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs
Date: Mon, 20 Mar 2000 17:44:08 +0100 (MET)
From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
X-Sender: broeker AT acp3bf
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
cc: djgpp-workers AT delorie DOT com
Subject: Re: Unnormals???
In-Reply-To: <Pine.SUN.3.91.1000320183001.26722O@is>
Message-ID: <Pine.LNX.4.10.10003201737120.25247-100000@acp3bf>
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 Mon, 20 Mar 2000, Eli Zaretskii wrote:

> 
> On Mon, 20 Mar 2000, Hans-Bernhard Broeker wrote:
> > The sign bit alone does not identify the 'real indefinite'. The mantissa
> > is also fixed. So the 'flag', if any, would be the whole 64 bits of
> > information, not just the sign bit.
> 
> Not really: if you flip the sign but leave the rest alone, the real 
> indefinite becomes a QNaN; you don't need to change the rest of the
> bits.

Well, the same happens if you manipulate any of the mantissa bits. So they
are exactly as necessary for the thing to be the 'real indefinite' as the
sign bit is.

Eli, it seems as if just because the real indefinite has its sign bit set,
by choice of Intel, you're trying to convince us that the sign bit of a
NaN had better be neglected completely. Given that the only 'special'
thing about real indefinite is that it is the only NaN that the FPU ever
generates out of the blue, that looks like you're putting to much weight
on this one item. Real indefinite, once present in a variable, or found in
an FPU register, is treated exactly like all other QNaNs. I.e. it only has
a different origin, but no different behaviour. 

Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.