On Fri, 13 Oct 2000 numpy-discussion-request@lists.sourceforge.net wrote:

having Python you indeed have bad *and* incomplete 754 support on every 754 platform it runs on.

Well, it depends on what you mean by "bad *and* incomplete 754 support". IEEE recommends specific semantics for comparison operators in language bindings, but I think their recommendations are undesirable from a programming language and software engineering point of view. If you follow IEEE semantics, you prohibit optimizers from optimizing in many cases and it contradicts type system semantics in some languages. Worst of all, programs that rely on IEEE semantics (in particular, of comparison operators) give no lexical indication that they do so; they will simply do something wrong, like go into an infinite loop or terminate a loop prematurely. I think it's best to raise an exception for any expression involving a NaN, unless the programmer explicitly indicated that he wants a NaN result and IEEE semantics. Another good approach is to provide separate IEEE operators and leave the behavior of the built-in operators on IEEE special values explicitly undefined. This keeps people from relying on one behavior or the other. To me, the worst possible choice is to "implement IEEE semantics correctly", i.e., in the way the IEEE authors envisioned it. (Of course, IEEE is reasonably nice from a numerical point of view; I just think they overextended themselves when talking about language bindings).

(*) Quiz: *if* you can manage to trick Python into creating a NaN on your particular 754 platform, does the Python expression NaN == 1.0 return true, false, or raise an exception? Answer before you try it. Then try it on enough 754 platforms until you give up trying to guess in advance. NaN == NaN is predictable in Python, and is the one 754 feature Python guarantees won't work correctly on any 754 platform (although I've heard that it loses this predictability when run using NumPy's flavor of comparisons instead of core Python's).

This is just the sort of issue I was referring to. In many dynamic languages, the assumption is that pointer quality implies object equality. That's a perfectly reasonable semantic choice. While Python may not implement "754 correctly" in the sense of the (probably) Fortran-thinking IEEE floating point designers, I think Python's choice is correct and should not be altered. People who really want IEEE floating point comparison operations can use something like ieee.equal(a,b). That alerts the reader that something special is going on, it will fail on non-IEEE platforms (indicating that the code wouldn't work correctly there anyway), and it makes only the code that needs to pay the price for strict IEEE conformance. Cheers, Thomas.