[SciPy-user] Re: nan puzzle
Jim.Vickroy at noaa.gov
Thu Jul 14 12:47:59 CDT 2005
Thanks for the background information.
I was (perhaps incorrectly) thinking that NaN, as discussed in this
thread, must not be implemented(defined) in the same way that Python
None is defined because comparing objects to None via 'is' does work as
expected; in a sense, None is a singleton. However, it clearly does not
work as expected for floating point constant objects like 2.0.
Grant Edwards wrote:
>On 2005-07-14, Jim Vickroy <Jim.Vickroy at noaa.gov> wrote:
>>So without knowing the implementation of nan (e.g., is it
>>truly unique package-wide),
>I don't understand how there can even be "an implimentation of
>nan" in this context. In IEEE floating point a NaN is any of a
>large set of bit patterns. Assuming a 64-bit IEEE float (which
>is what all the Python implimentations I know of use), there
>are 16 million unique bit patterns that are NaNs. Half of them
>are signalling NaNs, half are quiet NaNs. Half of them are
>positive, half of them are negative.Though the sign of a NaN
>is, in practice, meaningless, the sign bit can be either
>postive or negative.
>There is no unique NaN FP value. Since there is no unique
>_value_ it's rather pointless to talk about a module-wide
>implimentation of a NaN value. It's like talking about an
>object that contains "the negative number", and wondering
>whether that implimentation of "negative" is module-wide or
>If you want to know if a name is bound to a floating point
>object object that has one of the NaN bit-patterns, then you've
>got to look at the bit pattern.
>It's handy to have a name bound to one of those bit patterns
>for when you want to use one, but having a name bound to one of
>those bit patterns is uselss when you want to decide if some
>other FP object contains a NaN.
>>I would not expect x is nan to evalutate to True.
More information about the SciPy-user