X-Authentication-Warning: acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs Date: Thu, 16 Mar 2000 17:46:25 +0100 (MET) From: Hans-Bernhard Broeker X-Sender: broeker AT acp3bf To: Eli Zaretskii cc: djgpp workers list 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 Thu, 16 Mar 2000, Eli Zaretskii wrote: > On Thu, 16 Mar 2000, Hans-Bernhard Broeker wrote: > > > > But the sign of a negative nan and inf should be printed regardless of > > > > any sign format specifier. > > > > > > Why ``should''? I don't think the standard says that, since some > > > architectures don't support signed NaNs. > > > > That doesn't really matter. To cite the draft C99, on the '+' > > option to printf format specs: > > We do comply with the standard when `+' is in the format. I was > referring to the case when it isn't, since Martin said ``regardless of > any sign specifier''. I didn't cite the standard because of the behaviour with '+' set, but because of the second sentence. I'll underline it: > > + The result of a signed conversion always begins with a > > plus or minus sign. (It begins with a sign only when ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > a negative value is converted if this flag is not ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > specified.)258) ^^^^^^^^^^ In other words: if the '+' option is not set, and the value is negative, the output begins with a sign. The wording is a bit distracting because of the word 'only' in it, but that's what I think this sentence says. Applying this to a NaN means that a negative NaN should always have a minus in front of it, on printout, regardless of any option to the printf() format. > That's the crux of the problem: the Intel (probably also IEEE) definition > of a NaN includes the sign bit set. Does it? My books both say that there are negative and positive NaNs, i.e. the sign bit of a NaN is treated exactly like in all other FP numbers. > So what would you suggest to be produced by nan()? Will the result have > the sign bit set or not? A positive NaN, as nan(string) is supposed to behave exactly as strtod("NAN(string)"), i.e. there is no minus in front of it. > What about the expression "-nan()"? Whatever the FPU usually does if you multiply a positive NaN by minus 1. We don't have control over the execution of -nan() by the compiler, so we have nothing to choose, here. If the user wants a negative Nan, she should call strtod("-NAN") or strtod("-NAN(string)"), respectively. strtod() may calculate its result as -strtod("NAN)"), in turn, as far as C99 is concerned, but we could always choose the more sensible direct path, here, or at even set the sign bit by direct bit manipulation, instead of multiplying by -1. > And how all of these cases will be printed by printf, with or without > the `+' in the format specifier? Exactly like with non-special numbers. The decision regarding '+' or '-' sign output depends only on the sign bit of the number and the printf format options chosen (' ', '+' or none of them), really. I don't see any special treatment for NaN, Infinity or anything, here, neither in the C standard, nor in my x87 hardware book. Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.