delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2000/03/15/16:48:45

X-Authentication-Warning: acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs
Date: Wed, 15 Mar 2000 18:33:30 +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
Subject: Re: Unnormals???
In-Reply-To: <200003151627.LAA20064@delorie.com>
Message-ID: <Pine.LNX.4.10.10003151806320.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, Dieter Buerssner wrote:

> On 15 Mar 00, at 15:05, Hans-Bernhard Broeker wrote:
> 
> [...]
> > "inf", "infinity", "nan", or "nan{somestring}", where "{somestring}"
> > is an implementation-defined string. 
> 
> So your interpretation differs with mine.
> With your interpretation "nansqrt" would be correct, while I thought
> the braces were not optional and it must be nan(sqrt).

On second reading, I stand corrected. The braces are required (a bit
hard to tell in the ASCII version of the document, though).

[...]
> For types float and double, every possible bit pattern is either a
> normal number, a subnormal number, an Infinity, or a NaN, or zero.
> 
> This is  not true for type long double, because long double does not
> have an implicit set msb in the mantissa. 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. They are not numbers so we could
> call them NaNs.

I don't think it's up to us to decide whether a given unnormal is a NaN or
not. NaNs are a clearly defined set of values, in IEEE and 387 floating
point bit patterns. A zero MSB in the mantissa alone is not enough to
render a given pattern a NaN, by that definition, unless my memory hast
completely left me, here.

> This is very similar to the example Eli mentioned about the
> NULL-pointer for %s. Printing <null> can't be in contradiction to the 
> Standard, because we deal with undefined behaviour.

But there is no undefined behavour allowed for printf() of a double, by
the new standard. By the old C90, it was implementation-defined, I think,
just like everything else you can do with an Inf or NaN.

> Perhaps there is a reader of this list, who has access to IEEE
> floating point standards, and can check whether it allows an 
> unnormalized mantissa with finite exponent for the extended
> IEEE type.

I have the ISO/IEC 10967-1:1994 document on 'Language independent
arithmetics', which is mentioned by the C99 standard, as superceding the
IEEE 754 one. On quick glance, it only ever mentions 'denormals' (which
have been called 'subnormals' in this thread), and the property of a given
number to be 'normalized' (mantissa MSB is 1). There's no special-casing
for unnormals whatsoever.

Only if the exponent is at maximum, and the mantissa is not all zeroes, is
a given bit pattern a NaN. Unnormalized numbers other than the denormals
shouldn't usually need any special treatment at all.  If memory serves,
they're auto-normalized on reading into the FPU. Hard facts tomorrow (I'll
bring in that book I mentioned).

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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019