X-Authentication-Warning: acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs
Date: Wed, 22 Mar 2000 20:34:17 +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: <200003221853.NAA21885@delorie.com>
Message-ID: <Pine.LNX.4.10.10003222025470.29657-100000@acp3bf>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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
Precedence: bulk

On Wed, 22 Mar 2000, Dieter Buerssner wrote:

> On 22 Mar 00, at 19:17, Hans-Bernhard Broeker wrote:
[...]
> > unnormal or pseudo-NaN, we'ld print the normalized nunber.

> I think, this would be misleading. With my system, arithmetics with 
> an unnormal results in a NaN. 

> printf("%Lf\n", unnormal); /* prints the renormalized number */
> /* work with the number */
> unnormal += 1.0;
> printf("%Lf\n", unnormal); /* prints nan */

You have a point there. Thinking about it again, silently ignoring
unnormals in printf would only make sense for the old (<= 287) type of
Intel FPU's, or if we changed the setup to always have an exception
handler for SIGFPE that catches invalid operation exceptions caused by
unnormals, and translates them into normals, before going on.

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. C99
leaves us no other practicable choice.

OK, so on to the next issue: should we print the bit pattern of a NaN,
i.e. make use of the optional string to output the full information about
a NaN? Or just output "[-]NAN", with the possible specializations
"(unnormal)" and "(indefinite)", and maybe "(signaling)" and "(quiet)"
too?


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