delorie.com/archives/browse.cgi | search |
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 |
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 |
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
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |