#18246: remove naive __hash__ from SageObject
-------------------------+-------------------------------------------------
       Reporter:         |        Owner:
  vdelecroix             |       Status:  new
           Type:         |    Milestone:  sage-6.9
  defect                 |   Resolution:
       Priority:  major  |    Merged in:
      Component:         |    Reviewers:  Volker Braun
  coercion               |  Work issues:
       Keywords:         |       Commit:
        Authors:         |  4d8ec2a1282b24064f93bc8bea5fe23ec08f1750
  Vincent Delecroix      |     Stopgaps:
Report Upstream:  N/A    |
         Branch:         |
  public/18246           |
   Dependencies:         |
-------------------------+-------------------------------------------------

Comment (by nbruin):

 Replying to [comment:39 tscrim]:
 > I actually don't like these changes:
 > {{{#!diff
 > -class VectorPartitions(Parent, UniqueRepresentation):
 > +class VectorPartitions(UniqueRepresentation, Parent):
 > }}}
 > Why does `UniqueRepresentation` have to come before `Parent`?

 Because `UniqueRepresentation` provides a hash that is fast and
 appropriate and `Parent` doesn't:
 {{{
 sage: Parent.__hash__
 <slot wrapper '__hash__' of
 'sage.structure.category_object.CategoryObject' objects>
 sage: UniqueRepresentation.__hash__
 <slot wrapper '__hash__' of 'sage.misc.fast_methods.WithEqualityById'
 objects>
 }}}
 In order to get the MRO right, `UniqueRepresentation` needs to appear
 before Parent:
 {{{
 sage: class A(UniqueRepresentation, Parent): pass
 sage: A.__hash__
 <slot wrapper '__hash__' of 'sage.misc.fast_methods.WithEqualityById'
 objects>
 sage: class B(Parent, UniqueRepresentation): pass
 sage: B.__hash__
 <slot wrapper '__hash__' of
 'sage.structure.category_object.CategoryObject' objects>
 }}}

 Once all default hashes have been deleted and no classes in the MRO of
 Parent offer a hash function, the order doesn't matter. Until then,
 `UniqueRepresentation` has to come first.

 > Also can someone explain to me why are `RiggedConfigurations` now
 showing machine dependent iteration order?

 The code is hard to follow, but in general, if enumeration somewhere
 involves a set or a dictionary, then results depend heavily on the hash
 used and the order in which the dictionary was constructed. I'd expect
 that a changed hash causes things to be enumerated in a different order
 (because a set or dict is storing its entries in a different order
 somewhere)

--
Ticket URL: <http://trac.sagemath.org/ticket/18246#comment:40>
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.

Reply via email to