Date:	Thu, 16 Mar 2000 11:42:02 +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, Dieter Buerssner <buers AT gmx DOT de>
Subject:	Re: Unnormals???
In-Reply-To:	<Pine.LNX.4.10.10003151904260.21378-100000@acp3bf>
Message-ID:	<Pine.SUN.3.91.1000316114140.3117C-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 Wed, 15 Mar 2000, Hans-Bernhard Broeker wrote:

> The real question would be if they can be
> validly interpreted as numbers, by the FPU, and if the FPU generates any
> exception if it has to do that. 'Invalid' is what the FPU decides to
> be invalid, IMHO.

The FPU treats these unnormals as invalid numbers.  That was the
reason to introduce the special treatment for them in the first place.
Please see the discussions we had on djgpp-workers, where Robert
Hoehne posted a short test program which blew the heck out of v2.02
vintage of _doprnt.  The reason was that the FPU treated these bit
patterns as NaNs, which fail all the conditional tests.

> > I don't think this is a good idea, because, unlike NaNs, unnormals 
> > *always* mean there's a bug lurking somewhere.  
> 
> Or someone's been a bit creative in making up floating point data from
> scratch...

It is still a bug (albeit a ``creative'' one): it means the program
generates an invalid FP number, which cannot be used in any FP
computation to yield a useful result.

> Think of someone trying to convert binary raw FP data from some
> exotic hardware to the PC. You'ld do that by taking the input as a
> sequence of bytes, or even single bits, and build an x87 FP number from
> them. If it's faster to sometimes generate unnormalized numbers, the
> programmer shouldn't be punished by 'nan(unnormal)' or similar printouts,
> IMHO.

You seem to assume that the FPU has some way of dealing with these bit
patterns in a reasonable way.  This isn't true: the FPU treats them as
if they were NaNs; no useful FP result can ever be generated out of
their use.

So there's no ``punishment'' here.  Quite to the contrary, this is
IMHO a valuable debugging aid, exactly like "(null)".

> But we don't have the choice to print anything except, numbers, "inf"
> or "nan", effectively. At least by my understanding of the Standard,
> we haven't. 

Perhaps we could ask this on the appropriate news group, where someone
could clarify the standard.

I don't have anything about "NaN(unnormal)" if it's allowed, but I do
think that we should give a clear indication that this is _not_ the
standard IEEE QNaN/SNaN bit pattern.

- Raw text -