Mail Archives: djgpp-workers/2000/03/20/09:46:52
On Sun, 19 Mar 2000, Eli Zaretskii wrote:
> 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.
I take a somewhat broader view, here, it seems. Fact is, there is a sign
bit in NaN's, so what are we going to call a NaN with its sign bit set, to
distinguish it from one with that bit unset? *No* mathematical reasoning
whatsoever makes sense in the realm of NaNs, so I fail to see what might
stop us from using a term like 'negative'. 'negative' will not have the
usual meaning, in a NaN, sure, but there is also no other meaning it could
be confused with, either. 'negative' is free for us to define, in the
context of NaNs.
Actually, by our current 'printf("%+Lf", some_nan_with_sign_bit_set);
outputting "-nan", we already have defined what 'negative' means,
regarding NaNs, sort of. If we didn't want to call such NaNs 'negative',
the C99 standard would force us to output "+nan", instead (only negative
numbers get a minus).
> > 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''.
Yes. But what's so wrong with outputting '-nan' for that, or maybe
"-nan(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.
Most people will actually alreay be confused by seeing the string 'nan' in
their numeric output, in the first place. The addition of a '-' in front
of it will not increase their confusement any further, I think.
> 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.
But such test suites are not forced to ask for the sign explicitly,
by definition of the language. They could just as well use "%Lf" as
their format, instead, and still require a '-' in the output for
a NaN with sign bit set.
> > 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.
No. QNaN is the name of the whole class of quiet NaNs. There are 2^62 of
them with sign bit set, and another 2^62 with sign bit unset. Only one of
them is the 'real indefinite', and only one other is identical to it with
the exception that its sign bit is not set.
> And that is what our
> nan() (in libm.a) returns.
The problem with using real indefinite is what, AFAICS, strtod("nan") and
strtod("-nan") are not supposed to give the same number. So we cannot very
meaningfully output real indefinite for nan(NULL), or nan(""), unless we
completely artificially reverse the meaning of the sign bit of a NaN in
output, completely (i.e. output 'positive' NaNs with a minus in front of
them).
> > 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.
Yes, of course.
> 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.
There are no 'computations', in that example. the first printf() of
sqrt(-1) yields a string. From there on, only conversion functions between
character representation and binary floating point format are used. These
have to be implemented NaN-transparent, as I read the C99 standard.
> Also, it's quite probable that strtod will call nan() to generate a
> NaN when it sees the string "nan".
No, it's the other way round: nan() is defined in terms of what strtod()
does with an input string of "nan" or "nan(string)" (and an optional minus
sign).
> If nan() generates something other
> than real indefinite, we cannot hope for identity.
Well, of course, if we only implement nan() to the bare minimum (i.e. all
calls of it generate the *same* NaN pattern, neglecting any optional
string in the parentheses following it, even if present), then that single
possible result has to be the same as the one we get for sqrt(-1) and
similar cases.
> > 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.
A negative NaN still is a NaN. So those descriptions will still be true.
And of course, there's nothing to stop us from detailing this
implementation-defined behaviour in our own docs.
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.
- Raw text -