"Tom Anderson" <[EMAIL PROTECTED]> wrote: > > But NaNs are _not_ things. > > I disagree. A NaN _is_ a thing; it's not a floating-point number, for > sure, but it is a symbol which means "there is no answer", or "i don't > know", and as such, it should follow the universal rules which apply to > all things.
It seems that the standard semantics of NaN is closer to NULL values in ANSI SQL, that is "unknown", "not available". In this sense, if you have two 'things' you don't know, you can't say they are equal simply because you don't know them ! > > Since INF-INF doesn't have an answer, we can't do this: > > > > x = inf - inf > > y = inf - inf > > > > and expect that x == y. > > I think we can. Both x and y have the same value, a value of > indeterminacy. NaN is a rigidly defined value of doubt and uncertainty! In this case, however, I would agree. x and y above are not assigned a label of 'unknown'; they are derived from an operation among valid *known* values, so NaN here means 'invalid' rather than 'unknown'. It makes sense to have x==y, because x and y are the outcome of the *same* invalid operation. Similarly, if z=0/0, z would also be invalid, but different from x and y, since it is the result of a different invalid operation. This brings us to the many-NaN situation. George -- http://mail.python.org/mailman/listinfo/python-list
