delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2000/03/22/13:22:03

X-Authentication-Warning: acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs
Date: Wed, 22 Mar 2000 19:17:22 +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: <200003221719.MAA17164@delorie.com>
Message-ID: <Pine.LNX.4.10.10003221853480.29657-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 22 Mar 00, at 15:44, Hans-Bernhard Broeker wrote:
> 
> [I added four zeroes in the next two lines]
> 
> > > >  pos_nanshort = 7fff 0001 0000 0000 0000
> > > >  neg_nanshort = ffff 0001 0000 0000 0000
> [...]
> > So they are 'Pseudo-NaN', in the sense that they look a bit like NaN,
> > but aren't, as they do not have the leading '1' bit in the mantissa
> > required for NaNs, or any number that is not an unnormal.
[...]
> That I thought, that these numbers are "normal" NaNs comes from the
> reading of a paper by David Goldberg (What every Computer Scientist 
> should know about Floating-Point Aritmetic).  In this paper he 
> defines a IEEE NaN as any number with an exponent of emax+1 and any 
> non-zero mantissa. I think David Goldberg was working on the IEEE 
> standards, so I trusted this definition.

His definition is correct, but only for float and double, not for long
double. Otherwise, he wouldn't have been speaking of a 'non-zero'
mantisssa. That definition silently assumes the hidden leading 1-bit in
all mantissae in the two shorter types. In long double, that 1-bit must be
present explicitly, lest the number be unnormalized.

> Anyway, to be in conformance with C99 for printf, and to be 
> consistant with copysign and signbit, I think for NaNs (quiet and 
> signalling) and also for pseudo NaNs, printf should print [-]NAN.
> For unnormals, it could print [-]NAN(unnormal) or [-]NAN.

I'm not entirely sure we really need to 'support' unnormals, at all, in
this way. It think it'd make more sense to silently normalize them, and
print what they come up as, after normalization, i.e. for an unnormal or
pseudo-NaN, we'ld print the normalized nunber.

After all, an unnormal is exactly equal in value to exactly one other,
normalized bit pattern, so why should we bother treating such equal-valued
bit patterns as different?

The linux libc5 I'm using here operates similarly, i.e. an unnormal passed
to printf() is automatically normalized, before display, but if the
product of an unnormal and a normal gives 'real indefinite', because of
the invalid operation exception that occurs.

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