Mail Archives: djgpp-workers/2000/03/16/13:19:32
On Thu, 16 Mar 2000, Eli Zaretskii wrote:
> On Thu, 16 Mar 2000, Hans-Bernhard Broeker wrote:
[...]
> 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.
Ah, that one. Yes, I've seen it being discussed.
> 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?
Well, if Intel decided that the 'standard' NaN was to be negative, then so
be it. They probably only chose it because of the 'nice' binary form: a
series of 1 bits, then a series of 0 bits. I see no reason not to print it
as negative, except for the a bit of irritation to some readers of the
output. If we decide to make use of the optional n-char-sequence in DJGPP,
we could output
"-nan(indefinite)"
for this particular one, but I don't think that would help much. The real
message, for these cases, is that there was a NaN coming out of the
calculation, not which of them it. Checking for 'indefinite' as a special
NaN might be a waste of time and effort.
Signs of NaNs should always be output, IMHO.
I'm undecided as to whether we should use the optional n-char-sequence. It
might be useful for distinguishing SNaN and QNaN, sure, but I doubt many
DJGPP coders will ever actually use the many different bit patterns of
NaNs can be used for anything, so there's not much need to print them.
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.
> > 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.
So let's not do that, then.
> > 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).
I'll have to carefully check if the 387 description says anything about
conservation of the sign bit in operations with a QNaN, and in conversion
from SNaN to QNaN. If sign bits are preserved, fmul(-1) is easier and
faster than extraction from an FP register to memory, bit-fiddling and
storing the result back into the FPU.
> 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. NaNs themselves cannot be
compared meaningfully, anyway, so there's no other condition to meet. My
position would be for these two identical strings to be either "-nan",
"-nan(quiet)", or "-nan(indefinite)", depending on wether we choose to use
the nan(string) style or not.
> 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.
I'd say it does, with the exception of printf("%d", -nan(NULL)), which
IMHO should output a minus sign.
> > > 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 '-'
[...]
> Would you like to reconsider this now, with the real indefinite being
> part of the picture?
No. Intel's choice for that real indefinite was suboptimal, IMHO, but we
have little other option than to stick with it.
After all, what's so wrong with a minus sign in the output?
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.
- Raw text -