spir ☣ wrote:

(Else there should be a distinction between equality assignment and identity assignemt? b = a # ==> a is b and a == b b := a # ==> a is b and possibly a == b

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. 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. (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.) -- Greg

2010/3/26 Greg Ewing :

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.

Such equality is not transitive (unless 1000000000 and 1000000001 are equal as ints which would be nonsense). The original problem with NaN is a consequence of an unfortunate decision to unify numeric equality with object equivalence. If they were distinguished, their behavior would be obvious: NaN != NaN NaN eq NaN 0.0 == -0.0 0.0 ne -0.0 42 == 42.0 42 ne 42.0 Hash tables would use object equivalence of course. If you have a type for a time which includes the local time and the time zone, and < > <= >= compare which time is earlier, then numeric == should be true for times denoting the same time through different time zones, but they should not be equivalent. Lisp and Scheme distinguish these relations. -- Marcin Kowalczyk

Marcin 'Qrczak' Kowalczyk writes:

The original problem with NaN is a consequence of an unfortunate decision to unify numeric equality with object equivalence. If they were distinguished, their behavior would be obvious: NaN != NaN NaN eq NaN

What do you mean by that? NaN is a class, not an instance!

0.0 == -0.0 0.0 ne -0.0 42 == 42.0 42 ne 42.0

As for the other examples, I can only sigh, 'Ah, the joys of "general abstract nonsense".'[1] I have some (abstract) sympathy for Mark's proposal for a with_nonstop_arithmetic context manager, but isn't it really a YAGNI for the Python language? (As opposed to high performance modules like numpy.) Footnotes: [1] I refer to Bourbaki's(?) name for category theory.

Bruce Leban writes:

(Personally, I would have made them non-hashable so you couldn't accidentally stick one in a dict but that's another problem.)

No, it's not. AIUI, that is one of the main issues that's being discussed in this thread. Most people seem reasonably satisfied with other behavior, so the discussion bounces back and forth between whether NaNs should be hashable (and, perhaps more often, whether they should all be equal or not), and how any change in identity or equality behavior might affect computations in existing programs.

Masklinn wrote:

Excuse me but NaNs propagate right? So we'd have not only float('nan') == float('nan'), but also float('nan') = float('nan') + 1 right?

The fact that one of the operands was a NaN propagates, but it doesn't have to be that particular NaN object. So NaN + 1 could create a new NaN object to return as its result.

[Meyer:]

...

It is rather dangerous indeed to depart from the fundamental laws of mathematics.

The very idea of IEEE-754 floats are a a definite departure from the fundamental laws of mathematics,

They're a departure from the laws of *real numbers*, but Meyer is using the word "mathematics" in a much broader sense here -- meaning any formal system that you can reason about rigorously. If your formal system has a notion of equality but includes values that don't compare equal to themselves, it seriously screws up your ability to reason about it. For Meyer, this is a *big* problem, because making it possible to reason rigorously about programs is something that Eiffel gets really anal about^H^H^H^H^H^H^H^H^H^H ^H^H^H^H^H^H one of the underpinnings of Eiffel's design. The more I think about it, the more I think that the only reason for needing NaNs in the first place is if you don't have, or don't want to use, an exception mechanism. As Meyer points out, treating NaN == NaN as false is not fundamentally any more correct than treating it as true. One interpretation or the other might be appropriate in a particular algorithm, but this needs to be considered on a case-by-case basis. So the *pythonic* way to handle NaNs is not to have them at all, but to raise an exception whenever an operation would produce a NaN. Code that knows what to do can catch the exception and proceed appropriately. Another possibility is to extend the boolean type with a NaB that propagates in the same way as a NaN. But something still has to give somewhere, because what happens when you do this? x = float('nan') y = float('nan') if x == y: ... else: ... If NaN == NaN is a NaB, then neither branch of the 'if' is appopriate, so the only correct thing to do would be to raise an exception when trying to branch on a NaB. So we have three correctness-preserving possibilites: 1) Always raise an exception as soon as a NaN is produced. 2) Propagate NaNs through arithmetic but raise an exception when attempting to compare them. 3) Return a NaB when comparing NaNs, and raise an exception when attempting to branch on a NaB. -- Greg

On Fri, 26 Mar 2010 15:01:46 +1300 Greg Ewing wrote:

The more I think about it, the more I think that the only reason for needing NaNs in the first place is if you don't have, or don't want to use, an exception mechanism.

As Meyer points out, treating NaN == NaN as false is not fundamentally any more correct than treating it as true. One interpretation or the other might be appropriate in a particular algorithm, but this needs to be considered on a case-by-case basis.

[In a language or a given case where yielding a NaN does not raise an exception from scratch.] It seems to me there are various comparison cases (esp. in an OO language, case 2): -1- Comparing (any) Nan to non_NaN should return False. a = <expr yielding a NaN> b = 1 a == b # ==> False -2- Comparing a given NaN with itself should return True. a = <expr yielding a NaN> b = a a == b # ==> True -3- Comparing various NaNs is the undefined case. Actually, I think it's the only case where a theoretical NaB makes sense. In my opinion, as Greg says, the python way would here be raising an exception. But only in that case. Denis ________________________________ vit esse estrany ☣ spir.wikidot.com