X-Authentication-Warning: acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs Date: Wed, 15 Mar 2000 18:33:30 +0100 (MET) From: Hans-Bernhard Broeker X-Sender: broeker AT acp3bf To: djgpp-workers AT delorie DOT com Subject: Re: Unnormals??? In-Reply-To: <200003151627.LAA20064@delorie.com> 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, Dieter Buerssner wrote: > On 15 Mar 00, at 15:05, Hans-Bernhard Broeker wrote: > > [...] > > "inf", "infinity", "nan", or "nan{somestring}", where "{somestring}" > > is an implementation-defined string. > > So your interpretation differs with mine. > With your interpretation "nansqrt" would be correct, while I thought > the braces were not optional and it must be nan(sqrt). On second reading, I stand corrected. The braces are required (a bit hard to tell in the ASCII version of the document, though). [...] > For types float and double, every possible bit pattern is either a > normal number, a subnormal number, an Infinity, or a NaN, or zero. > > This is not true for type long double, because long double does not > have an implicit set msb in the mantissa. 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. They are not numbers so we could > call them NaNs. I don't think it's up to us to decide whether a given unnormal is a NaN or not. NaNs are a clearly defined set of values, in IEEE and 387 floating point bit patterns. A zero MSB in the mantissa alone is not enough to render a given pattern a NaN, by that definition, unless my memory hast completely left me, here. > This is very similar to the example Eli mentioned about the > NULL-pointer for %s. Printing can't be in contradiction to the > Standard, because we deal with undefined behaviour. But there is no undefined behavour allowed for printf() of a double, by the new standard. By the old C90, it was implementation-defined, I think, just like everything else you can do with an Inf or NaN. > Perhaps there is a reader of this list, who has access to IEEE > floating point standards, and can check whether it allows an > unnormalized mantissa with finite exponent for the extended > IEEE type. I have the ISO/IEC 10967-1:1994 document on 'Language independent arithmetics', which is mentioned by the C99 standard, as superceding the IEEE 754 one. On quick glance, it only ever mentions 'denormals' (which have been called 'subnormals' in this thread), and the property of a given number to be 'normalized' (mantissa MSB is 1). There's no special-casing for unnormals whatsoever. Only if the exponent is at maximum, and the mantissa is not all zeroes, is a given bit pattern a NaN. Unnormalized numbers other than the denormals shouldn't usually need any special treatment at all. If memory serves, they're auto-normalized on reading into the FPU. Hard facts tomorrow (I'll bring in that book I mentioned). Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.