Mail Archives: djgpp-workers/2000/03/19/05:32:20
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.
- Raw text -