Re: Looking for someone who contacted me a while back.

[thompson(at)orpheus.nascom.nasa.gov (William Thompson)]

davidf@dfanning.com (David Fanning) writes:

>Todd Bowers (tbowers@nrlssc.navy.mil) writes:

>> Damn! is there *anything* you don't know, David??

>Uh, yeah, *why* Where(a EQ !Values.F_NAN) doesn't work. :-)

Once you realize that

	IDL> Print, Where(a NE a)

does work, then it makes a certain amount of sense that

	IDL> Print, Where(a EQ !Values.F_NAN)

doesn't work.  Any comparison of an NaN value to another value returns false,
even if that other value is also an NaN value.

Actually, it's wrong to think of NaN as a specific value.  Instead it's a
collection of "values" (bit patterns), all of which are interpreted as NaN.
There are, in fact, 16,777,214 different bit patterns which translate into a
single precision NaN value, and 9,007,199,254,740,990 possible double precision
NaN values.  Half of these values are displayed by IDL as "-NaN" when printed
to the screen, but that's actually not required by the IEEE floating point
standard.

It would have made a certain amount of sense for RSI to adopt the convention
that the expression "a EQ b" would return true when the comparison was between
two NaN values, regardless of the exact bit pattern.  Instead they adopted the
convention that this returns false when either (or both) of the variables are
NaN.  It seems counterintuitive, but once you get the hang of it, it's not too
bad.  It does have the nice property that, if the variables A and B are arrays,
then "Where(a EQ b)" only returns the indices of valid numbers.

William Thompson

P.S.  In case you're interested, a floating point number is considered to be
NaN if the exponent field is all ones, and at least one of the bits in the
mantissa field is also set to one, regardless of the sign bit.  If the exponent
field is all ones, and the mantissa field is all zeroes, then the value is plus
or minus infinity, depending on the sign bit.  Everything else is a valid
floating point number.