Date: Sun, 19 Mar 2000 10:46:00 +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: > Well, if Intel decided that the 'standard' NaN was to be negative, then so > be it. It's not negative: it doesn't make sense to talk about NaN being negative, because it's not a number; any mathematical definition of a negative number will fail with a NaN. > The real message, for these cases, is that there was a NaN coming > out of the calculation, not which of them it. Exactly. And more often than not, the NaN they will see is this specific type, the ``real indefinite''. > Signs of NaNs should always be output, IMHO. I disagree. A sign of a NaN has no real importance in my view. So showing the always-negative sign will just confuse people. OTOH, there are programs, such as test suites, which know what they are doing and want the sign bit in print for a reason. So I thing the compromise of printing the sign only when the format requests this is a reasonable one. > The result of nan(NULL) and/or nan("") should be some 'standard NaN', but > I object to using the negative 'indefinite real' for that. Its positive > (but nameless) counterpart would be a good choice. That counterpart does have a name: it's a QNaN. And that is what our nan() (in libm.a) returns. > > 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? > > I don't think so, no. The only thing to be made sure of is that after > > sprintf(buffer1, "%d", sqrt(-1)); > result = strtod(buffer1, NULL); > sprintf(buffer2, "%d", result); > > the two buffers contain identical strings. I believe you meant to say %f, not %d. Anyway, I didn't check, but I won't be surprised if the above identity is impossible to achieve: I'm afraid that the real indefinite doesn't propagate intact through the computations. Also, it's quite probable that strtod will call nan() to generate a NaN when it sees the string "nan". If nan() generates something other than real indefinite, we cannot hope for identity. > After all, what's so wrong with a minus sign in the output? It might mislead the uninitiated, and lead them to think that the negative sign was produced by some mysterious operation. All the docs, inclduing ours, tell that invalid operations result in a NaN, not a negative NaN.