Date: Thu, 16 Mar 2000 19:22:43 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Hans-Bernhard Broeker 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, Hans-Bernhard Broeker wrote: > > 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. Okay, my wording (and this whole discussion) was somewhat inaccurate, because apart of SNaNs and QNaNs, there's another beast involved here, which Intel calls ``real indefinite''. This is a special NaN that is generated by the FPU as a masked response to an invalid operation exception. This NaN has its sign bit set. Naturally, most of the NaNs an average program will ever see are of this special kind. So how we treat this NaN is very important. So now, that we have introduced all of the different types of NaN, let me ask again: what shall we print for each and every type of them, with and without a sign, and what should nan() return? > > 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. This is not an option if nan() produces the real indefinite. > 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. The question is what we _should_ do, not what we _could_ do. The standard is deliberately vague here (although less so than C89). Don't forget that a NaN can be produced as sqrt(-1), for example. Do we want that NaN be the same as what ``strtod("NaN")'' produces? What the library currently does (and I'm not sure how consistently, but there is some consistency in it, as the Cygnus test suite demonstrates) is that it silently treats all NaNs the same, and treats the real indefinite as a negative NaN. Does that comply to C99? I don't know. > > 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. Would you like to reconsider this now, with the real indefinite being part of the picture?