delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2000/03/27/07:24:30

X-Authentication-Warning: acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs
Date: Mon, 27 Mar 2000 14:10:38 +0200 (MET DST)
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: <200003260433.XAA26337@mescaline.gnu.org>
Message-ID: <Pine.LNX.4.10.10003271356370.2109-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 Sat, 25 Mar 2000, Eli Zaretskii wrote:

> 
>    So, yes, I'm now convinced we should treat unnormals like NaN, even though
>    the Intel/IEEE definition of a NaN doesn't really hold for them.
> 
> I disagree.  Making the unnormals stand out is a valuable debugging
> aid, since an unnormal can never be a result of any meaningful
> computation, unlike a NaN.

Sure. I didn't meant to say that unnormals should be treated as
indistinguishable from NaN, i.e. the distinction is to be kept, at least
in situations like printf("%Lf"). But in the definition space provided by
C99, we have only limited choices what to fpclassify() an unnormal as:

	infinite
	NaN
	normal
	subnormal
	zero

An unnormal or pseudo-nan, as defined by intel/IEEE, fits none of these
categories but 'NaN' or 'normal'. In arithmetic operations, with
SIGFPE(invalid) blocked, as we do it, an unnormal automatically turns into
a NaN. OTOH, unnormals and pseudo-nan can in principle be associated with
a unique, normalized value that is either normal or subnormal, so we could
classify them as such, too.  If we follow this second route, the only
problem is when and how to do that conversion. We'ld have to put in a
SIGFPE default handler to do it for us, I think.

>    C99 leaves us no other practicable choice.
> 
> Since C99 doesn't mention the unnormals, and since they aren't NaNs, I
> don't see how the standard prevents us from reporting unnormals as such.

The standard gives a fixed list of classes of floating point values. It
seems to not allow for any extension of that list, either. Unnormals
aren't covered by any of those classes, so we'll have to subsume them into
one of them. NaN is the most natural choice, I think. I'm not voting
against treating them specially in printf(), where the standard does leave
us the choice to add explanatory text to the "nan" output. But for all
other situations, our blocking of SIGFPE(invalid operation) effectively
makes unnormals turn into NaN, already.

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