[Python-ideas] Why is nan != nan?

[spir ☣]

On Fri, 26 Mar 2010 14:25:06 +1300
Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:

> Eiffel's position on this seems to be that there should
> be no distinction -- a copy of a value should always
> compare equal to the original value, regardless of type.

Exactly, as I understand Eiffel. And, actually, I tend to support this point of view.

> Eiffel even seems to extend this to conversions, so that
> if you convert an int to a float, the resulting float should
> compare equal to the original int, even if some precision
> was lost in the conversion.

Yes, there is a post-condition equivalent to "assert(newval==val)". That's why (from this point of view):
>>> int(1.2)
1
>>> int(1.7)
1
should not even be possible (--> exception). The programmer has to tell the language about losing information, and thus losing equality, using eg round().
[The same indeed as when converting a huge int to float.]

> (Incidentally, that's one principle we would be choosing
> *not* to follow if we decide to compare floats and Decimals
> based on their exact values.)

What do you mean, exactly?
There may be a reference type, then the condition is Ref(val)==Ref(newval).
Or both type are referent (eg between int and float there may be loss of info in both directions).


Denis
________________________________

vit esse estrany ☣

spir.wikidot.com