#15904: Defining __eq__ without defining __ne__ or __cmp__: sage/combinat
-------------------------------------------------+-------------------------
Reporter: darij | Owner:
Type: defect | Status: new
Priority: major | Milestone: sage-6.2
Component: combinatorics | Resolution:
Keywords: sage-combinat, equality, | Merged in:
inheritance | Reviewers:
Authors: | Work issues:
Report Upstream: N/A | Commit:
Branch: | Stopgaps:
Dependencies: |
-------------------------------------------------+-------------------------
Description changed by darij:
Old description:
> I think one should always at least one of `__ne__` and `__cmp__` on a
> class when one defines `__eq__`, unless one really wants to have `!=` to
> behave differently from the negation of `==` (or one is happy with the
> `__ne__` inherited from the superclass; but then why would one redefine
> `__eq__` to begin with?):
>
> {{{
> sage: ContreTableaux(4) == ContreTableaux(4)
> True
> sage: ContreTableaux(4) != ContreTableaux(4)
> True
> }}}
>
> or also (here the `!=` is inherited from `CombinatorialObject`):
>
> {{{
> sage: Core([1,1],3) != Core([1,1],4)
> False
> sage: Core([1,1],3) == Core([1,1],4)
> False
> }}}
>
> Here is a result of searching for this antipattern in the sage/combinat
> subfolder:
> https://www.dropbox.com/s/lca1yfw1qsz6ycy/ne.txt
> Some of these do define `__cmp__`, but redefining `__ne__` might lead to
> a speedup, so I kept them in the file even if these are not bugs per se.
>
> Should we just fix them all robotically?
New description:
I think one should always define at least one of `__ne__` and `__cmp__` on
a class when one defines `__eq__`, unless one really wants to have `!=` to
behave differently from the negation of `==` (or one is happy with the
`__ne__` inherited from the superclass; but then why would one redefine
`__eq__` to begin with?):
{{{
sage: ContreTableaux(4) == ContreTableaux(4)
True
sage: ContreTableaux(4) != ContreTableaux(4)
True
}}}
or also (here the `!=` is inherited from `CombinatorialObject`):
{{{
sage: Core([1,1],3) != Core([1,1],4)
False
sage: Core([1,1],3) == Core([1,1],4)
False
}}}
Here is a result of searching for this antipattern in the sage/combinat
subfolder:
https://www.dropbox.com/s/lca1yfw1qsz6ycy/ne.txt
Some of these do define `__cmp__`, but redefining `__ne__` might lead to a
speedup, so I kept them in the file even if these are not bugs per se.
Should we just fix them all robotically?
--
--
Ticket URL: <http://trac.sagemath.org/ticket/15904#comment:1>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
