Annoying behaviour of the != operator

[John Roth]

"Jordan Rastrick" <jrastrick at student.usyd.edu.au> wrote in message 
news:1118255048.849018.259500 at g14g2000cwa.googlegroups.com...
> Well, I don't really want the objects to be comparable. In fact, to
> quote that PEP you linked:
>
>      An additional motivation is that frequently, types don't have a
>      natural ordering, but still need to be compared for equality.
>      Currently such a type *must* implement comparison and thus define
>      an arbitrary ordering, just so that equality can be tested.
>
> I don't want to order the objects. I just want to be able to say if one
> is equal to the other.
>
> Here's the justification given:
>
>      The == and != operators are not assumed to be each other's
>      complement (e.g. IEEE 754 floating point numbers do not satisfy
>      this).  It is up to the type to implement this if desired.
>      Similar for < and >=, or > and <=; there are lots of examples
>      where these assumptions aren't true (e.g. tabnanny).
>
> Well, never, ever use equality or inequality operations with floating
> point numbers anyway, in any language, as they are notoriously
> unreliable due to the inherent inaccuracy of floating point. Thats
> another pitfall, I'll grant, but its a pretty well known one to anyone
> with programming experience. So I don't think thats a major use case.

Two floating point numbers are equal if they are within epsilon of each
other. Epsilon, of course, depends on the application. I do floating
point compares quite nicely in PyFit, with intuitive results. It simply
requires you to know what you're doing rather than blindly following
the herd over the cliff.

That is, however, not the reason for the statement. The reason for the
statement is that the feature was motivated by the numerics package,
which has a number of special requirements, floating point exceptional
values only being one. Read the PEP.

John Roth
>