#13814: LazyFamily.__eq__ gives false positives.
------------------------------------+---------------------------------------
       Reporter:  cnassau           |         Owner:  sage-combinat
           Type:  defect            |        Status:  needs_review 
       Priority:  major             |     Milestone:  sage-5.6     
      Component:  combinatorics     |    Resolution:               
       Keywords:                    |   Work issues:               
Report Upstream:  N/A               |     Reviewers:               
        Authors:  Christian Nassau  |     Merged in:               
   Dependencies:                    |      Stopgaps:               
------------------------------------+---------------------------------------

Comment (by nthiery):

 Hi Christian,

 Replying to [comment:8 cnassau]:
 > > ``__eq__`` and ``__ne__`` are supposed to be implemented consistently;
 so
 > > _test_pickling is allowed to rely on this assumption. If the
 > > assumption fails, that's an equality bug which should be fixed in
 > > ``__eq__/__ne__`` and be tested in ``_test_equal`` (whenever
 possible).
 >
 > Well, I think it __is__ consistent to have
 >
 >    {{{
 >       sage: LazyFamily(Integers(),lambda i:i) ==
 LazyFamily(Integers(),lambda i:1*i)
 >       False
 >       sage: LazyFamily(Integers(),lambda i:i) !=
 LazyFamily(Integers(),lambda i:1*i)
 >       False
 >    }}}
 >
 > In my reading this conforms to the standard python requirements:
 >
 >    hashing only requires `__hash__` and `__eq__` in
 >    `http://docs.python.org/2/reference/datamodel.html#object.__hash__`
 >
 > The document also says
 >
 >    There are no implied relationships among the comparison operators.
 The truth of x==y does not imply that x!=y is false.

 That's right for Python. However Sage is more stringent about this and
 requires == and != to be consistent. Hmm, I am not sure this is
 documented anywhere though. Basically the idea is that we already have
 trouble maintaining a consistent specification and implementation for
 ==, so we can't really afford to also maintain a possibly different
 specification for != ...

 Cheers,
                      Nicolas

-- 
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/13814#comment:14>
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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/sage-trac?hl=en.

Reply via email to