Mail Archives: djgpp-workers/2003/02/27/05:53:33
Hi.
Richard said:
> ams AT ludd DOT luth DOT se wrote:
> > New file, djgpp/src/libc/c99/math/nan.c:
> > /* Copyright (C) 2003 DJ Delorie, see COPYING.DJ for details */
> > #include <libc/ieee.h>
> >
> > float_t __dj_nan = { 0x7fffff, 0xff, 0x0 };
> > +#define NAN __dj_nan
> What does isnan(NAN) give? Does this affect the results given by tests/cygnus
> at all?
Haven't tried (yet). But printf() prints it as "NaN" (unsure about
capitalisation).
> C99 says that NAN should be a quiet NaN.
>
> "A quiet NaN propagates through almost every arithmetic operation without
> raising a floating-point exception; a signaling NaN generally raises a
> floating-point exception when occurring as an arithmetic operand."
>
> Is NAN a quiet NaN? I don't know enough about floating-point to answer this
> question.
Of course. Some more quiet ones: { 0x5fffff, 0xff, 0x0 } and
{ 0x400001, 0xff, 0x0 }. Some signalling ones: { 0x3fffff, 0xff, 0x0 },
{ 0x1fffff, 0xff, 0x0 } and { 0x000001, 0xff, 0x0 }, It's the MSB in
the mantissa (of the fraction part) that differences them.
Some more questions:
1. Should we support "nan(0x233)" to set specific bits in the NaN?
I'm willing to do the strto{d,f,ld}() parts, but not the *printf()
part.
2. If we do 1, we need to agree on the format. Mostly it's
straightforward, like a hexvalue of the pertinent bits, but for the
sign bit. "nan(-0x2323)", "nan(N0x2323)", "nan(1,0x2323)" and
"-nan(0x2323)" are some possibilities. Same question for the
Signalling bit if we want to support making a SNaN.
Am not sure 1 is worth to bother about for as soon as the value gets
into the FPU I suspect it might coerce the bits to some other NaN.
Right,
MartinS
- Raw text -