From: Martin Stromberg <Martin DOT Stromberg AT lu DOT erisoft DOT se>
Message-Id: <200003161038.LAA26422@lws256.lu.erisoft.se>
Subject: Re: Unnormals???
To: djgpp-workers AT delorie DOT com
Date: Thu, 16 Mar 2000 11:38:42 +0100 (MET)
In-Reply-To: <Pine.SUN.3.91.1000316114140.3117C-100000@is> from "Eli Zaretskii" at Mar 16, 2000 11:42:02 AM
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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

Eli said:
> You seem to assume that the FPU has some way of dealing with these bit
> patterns in a reasonable way.  This isn't true: the FPU treats them as
> if they were NaNs; no useful FP result can ever be generated out of
> their use.

If the FPU treats them as nans, aren't they nans? Why are you saying
they aren't nans?

> I don't have anything about "NaN(unnormal)" if it's allowed, but I do
> think that we should give a clear indication that this is _not_ the
> standard IEEE QNaN/SNaN bit pattern.

No that's not allowed (literally). The "NaN" part should be "nan" or
"NAN", depending on the format specifier.

I suggest we print "nan(unnormal)" or "nan(unnormal0x<bit pattern>)"
where <bit pattern> is the bits of the double float in hexadecimal.


Right,

							MartinS