X-Authentication-Warning:	acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs
Date:	Wed, 15 Mar 2000 19:19:00 +0100 (MET)
From:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
X-Sender:	broeker AT acp3bf
To:	djgpp-workers AT delorie DOT com
cc:	Dieter Buerssner <buers AT gmx DOT de>
Subject:	Re: Unnormals???
In-Reply-To:	<Pine.SUN.3.91.1000315190729.20407Q-100000@is>
Message-ID:	<Pine.LNX.4.10.10003151904260.21378-100000@acp3bf>
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, Eli Zaretskii wrote:
> On Wed, 15 Mar 2000, Dieter Buerssner wrote:

> > So there will be 
> > bitpatterns, with a finite exponent and a non set msb in the 
> > mantissa. We called those unnormal in this threat. They could in 
> > principle be renormalized (when the mantissa is not zero). But I 
> > think, they are just invalid.
> 
> Yes, these numbers are invalid.  They cannot result from any FP 
> operation, only from passing arbitrary buffers to functions or casting 
> such buffers to long double.

Those buffers don't have to be 'arbitrary', just because they can't have
come from an FPU operation. 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.

> > They are not numbers so we could call them NaNs.
> 
> 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... 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.

> So it makes sense to tell 
> the user explicitly about this.  If we print NaN, the user cannot know 
> whether this is the normal IEEE NaN with its distinct bit pattern or 
> something else.

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. 

> Note that C9X and IEEE are two different standards which don't 
> necessarily coincide.

True, but part the C99 standard (no longer X, it's been ratified in 1999) 
explicitly refers to IEEE for some of its details, and explanations of
terms:

         -- IEC 60559 (also known as IEC 559  or  IEEE  arithmetic) |
            support                                                 |

(IEC 559 is kind of a successor to IEEE 754 and 854) IEC 559 support is
not fully mandatory, but it's closely linked with C99 nevertheless. The
ISO/IEC 10967 I mentioned earlier has a more general view on arithmetics
(both integer and FP), and is also referred to in C99 (App. H, in my
draft).

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

- Raw text -