X-Authentication-Warning: acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs Date: Wed, 20 Jan 1999 12:46:45 +0100 (MET) From: Hans-Bernhard Broeker X-Sender: broeker AT acp3bf To: djgpp workers list Subject: Re: Bug when printing long doubles In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com On Wed, 20 Jan 1999, Eli Zaretskii wrote: > On Wed, 20 Jan 1999, Hans-Bernhard Broeker wrote: > > > It should print the actual value. After all, even an unnormalized fp > > number does have a value. > > I thought about such a possibility (it seems that Linux, at least in some > versions, does that), but decided I don't like it. The reason is that if > you print it as a normal FP number, how does John Doe the programmer, who > has his program crash or produce NaNs, will ever be able to guess that > this number is the culprit? [...] > You can't multiply this number by anything: if you do, you get a NaN as a Hmmm... seems like I'll have to revisit my FPU literature again. I thought the FPU at least had a mode where it does not generate any exception, nor return NaN, when it's operating on unnormals... > > On a side issue: as per the C9x standard, it seems we'll have to change > > from 'NaN' and 'Inf' to 'nan' and 'inf' at some point in time. > > Does C9X indeed diverge from existing art so much? Do they disallow Inf > and NaN? Well, to quote the draft, revision 2, from the description of the fprintf '%f' format: A double argument representing an infinity is converted in one of the styles [-]inf or [-]infinity -- which style is implementation-defined. A double argument representing a NaN is converted in one of the styles [-]nan or [-]nan(n-char-sequence) -- which style, and the meaning of any n-char- sequence, is implementation-defined. The F conversion specifier produces INF, INFINITY, or NAN instead of inf, infinity, or nan, respectively.218) With the footnote 218 saying: 218When applied to infinite and NaN values, the -, +, and space flag characters have their usual meaning; the # and 0 flag characters have no effect. %e and %g are documented to behave like %f, on NaN and and infinity. Now, what does the 'style [-]nan' mean, exactly? As I read it, it means: print "nan", in exactly these letters, with an optional minus in front. The fact that all these 'style' strings are given in bold (in the pdf edition of draft 1, I have), and that the are written NAN, and INFINITY, in the case of %F/%G/%E, seems to support this. Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.