X-Authentication-Warning: acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs Date: Wed, 15 Mar 2000 19:19:00 +0100 (MET) From: Hans-Bernhard Broeker X-Sender: broeker AT acp3bf To: djgpp-workers AT delorie DOT com cc: 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, Eli Zaretskii wrote: > On Wed, 15 Mar 2000, Dieter Buerssner wrote: > > So there will be > > bitpatterns, with a finite exponent and a non set msb in the > > mantissa. We called those unnormal in this threat. They could in > > principle be renormalized (when the mantissa is not zero). But I > > think, they are just invalid. > > Yes, these numbers are invalid. They cannot result from any FP > operation, only from passing arbitrary buffers to functions or casting > such buffers to long double. Those buffers don't have to be 'arbitrary', just because they can't have come from an FPU operation. 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. > > They are not numbers so we could call them NaNs. > > 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... 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. > So it makes sense to tell > the user explicitly about this. If we print NaN, the user cannot know > whether this is the normal IEEE NaN with its distinct bit pattern or > something else. 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. > Note that C9X and IEEE are two different standards which don't > necessarily coincide. True, but part the C99 standard (no longer X, it's been ratified in 1999) explicitly refers to IEEE for some of its details, and explanations of terms: -- IEC 60559 (also known as IEC 559 or IEEE arithmetic) | support | (IEC 559 is kind of a successor to IEEE 754 and 854) IEC 559 support is not fully mandatory, but it's closely linked with C99 nevertheless. The ISO/IEC 10967 I mentioned earlier has a more general view on arithmetics (both integer and FP), and is also referred to in C99 (App. H, in my draft). Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.