Date: Thu, 16 Mar 2000 11:42:02 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Hans-Bernhard Broeker cc: djgpp-workers AT delorie DOT com, Dieter Buerssner Subject: Re: Unnormals??? In-Reply-To: Message-ID: 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, 15 Mar 2000, Hans-Bernhard Broeker wrote: > The real question would be if they can be > validly interpreted as numbers, by the FPU, and if the FPU generates any > exception if it has to do that. 'Invalid' is what the FPU decides to > be invalid, IMHO. The FPU treats these unnormals as invalid numbers. That was the reason to introduce the special treatment for them in the first place. Please see the discussions we had on djgpp-workers, where Robert Hoehne posted a short test program which blew the heck out of v2.02 vintage of _doprnt. The reason was that the FPU treated these bit patterns as NaNs, which fail all the conditional tests. > > I don't think this is a good idea, because, unlike NaNs, unnormals > > *always* mean there's a bug lurking somewhere. > > Or someone's been a bit creative in making up floating point data from > scratch... It is still a bug (albeit a ``creative'' one): it means the program generates an invalid FP number, which cannot be used in any FP computation to yield a useful result. > Think of someone trying to convert binary raw FP data from some > exotic hardware to the PC. You'ld do that by taking the input as a > sequence of bytes, or even single bits, and build an x87 FP number from > them. If it's faster to sometimes generate unnormalized numbers, the > programmer shouldn't be punished by 'nan(unnormal)' or similar printouts, > IMHO. 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. So there's no ``punishment'' here. Quite to the contrary, this is IMHO a valuable debugging aid, exactly like "(null)". > But we don't have the choice to print anything except, numbers, "inf" > or "nan", effectively. At least by my understanding of the Standard, > we haven't. Perhaps we could ask this on the appropriate news group, where someone could clarify the standard. 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.