Mail Archives: djgpp-workers/2000/03/19/05:22:18
On Fri, 17 Mar 2000, Eric Rudd wrote:
> There is the cryptic statement in the Pentium Pro manual, vol. 2, 7.6:
>
> "The sign bit of a NaN is not interpreted."
>
> What do you suppose they mean by that?
I interpret this as meaning that the sign bit of a NaN is a flag, not a
sign.
> I had already done the experiment to produce the table in my earlier message;
> I only incorrectly labeled +NaN as SNaN. Here is a hacky little program to
> try these things:
[snip]
> if (xys[i][1] == '$') { /* Motorola hex format */
> xys[i][1] = xys[i][0];
> sscanf(&xys[i][1], "%llx", &nd);
> } else if (xys[i][0] == '$') {
> sscanf(&xys[i][1], "%llx", &nd);
> } else { /* C hex format, decimal, or octal */
> sscanf(xys[i], "%lli", &nd);
> }
> x[i] = *((double *) &nd);
Beware of this last line: latest versions of GCC could do various tricks
with it, which makes loading literal infinities and nans not trivial.
You had better compiled without -O and examined the machine code.
> On my Pentium II, I found that -NaN = -NaN * -NaN; all other sign
> combinations produced +NaN.
This contradicts the Intel manual. (So what else is new?)
> 220When applied to infinite and NaN values, the -, +, and
> space flag characters have their usual meaning; the # and
> 0 flag characters have no effect.
>
> it seems that "real indefinite" must be printed out as negative.
Hmm? How do you see it from this footnote? IIRC it refers to the - and
+ flags in the format specifier, which we do support.
The issue at hand is do we need to print the negative sign when the
format is simply %f, say.
- Raw text -