www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1999/01/19/12:45:57

X-Authentication-Warning: acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs
Date: Tue, 19 Jan 1999 18:45:46 +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: Bug when printing long doubles
In-Reply-To: <58ca22ce.36a4c038@aol.com>
Message-ID: <Pine.LNX.3.93.990119183214.1969E-100000@acp3bf>
MIME-Version: 1.0
Reply-To: djgpp-workers AT delorie DOT com

On Tue, 19 Jan 1999 Kbwms AT aol DOT com wrote:

> > > Are you saying that you think such numbers should print as "NaN"?
> > I don't know about "should."   I would favor printing the thing in
> > hex or binary and let the user figure out what it means.

> I see nothing wrong with printing an item of poorly formed bits as NaN.

But I, for one, do. NaN is *not* an 'item of poorly formed bits'. It's
a clearly defined special kind of floating point data. It would be
outright wrong to claim something to be NaN, that actually isn't.

> Are there any words in any of the Standards that provide guidance here?

Let's see... (looking up C9x draft revision 2):

       [#3]  Floating  types  may  include  values  that  are   not
       normalized  floating-point  numbers,  for  example subnormal
       floating-point numbers (x!=0,e=emin,f1=0),  infinities,  and
       NaNs.15)  A NaN is an encoding signifying  Not-a-Number.   A
       quiet   NaN   propagates  through  almost  every  arithmetic
       operation without raising  an  exception;  a  signaling  NaN
       generally   raises   an   exception  when  occurring  as  an

So they're (better: will be) called 'subnormals' in C9x speak. There will
even be methods to classify a number as exactly one of subnormal, normal,
NaN, Infinity or zero, it seems. 

> Is this problem limited to poorly-formed long doubles?

Yes. Unnormals cannot happen in float or double, only in what we call
'long double' ('temporary real format', in the words of IEEE 754, I
think). That's because the crucial bit that has to be one in a normalized
fp number is not stored at all in float or double numbers: it's implicitly
assumed to be one, always. The fact that it's stored explicitly in long
double is most probably due to the fact that the numbers inside the FPU
are stored in that format. 

To give my personal view of this: subnormals really should not give any
exceptional behaviour in printf(). We should strive to ensure that
printf() of such a number does produce a valid answer, if possible.
Printing NaN would be a lie, simply put. 

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