#19331: Make Element.__hash__ return 0 by default
-------------------------------------+-------------------------------------
       Reporter:  vdelecroix         |        Owner:
           Type:  enhancement        |       Status:  needs_review
       Priority:  blocker            |    Milestone:  sage-6.9
      Component:  misc               |   Resolution:
       Keywords:                     |    Merged in:
        Authors:  Vincent Delecroix  |    Reviewers:
Report Upstream:  N/A                |  Work issues:
         Branch:                     |       Commit:
  u/vdelecroix/19331                 |  64053a2645456e605061a24952568e3c5e1f51e2
   Dependencies:                     |     Stopgaps:
-------------------------------------+-------------------------------------

Comment (by nbruin):

 Changing the runtime cost of data structures from what it should be should
 not be taken lightly. I don't think this change leads to acceptable
 behaviour (and it will be harder to find what's wrong: a hashing error is
 easier to debug)
 {{{
 class A(object):
   def __init__(self,N):
     self.N=N
   def __hash__(self):
     return 0
   def __eq__(self,other):
     return isinstance(other,A) and self.N==other.N
   def __call__(self):
     return self.N

 class B(object):
   def __init__(self,N):
     self.N=N
   def __hash__(self):
     return hash(self.N)
   def __eq__(self,other):
     return isinstance(other,B) and self.N==other.N
   def __call__(self):
     return self.N

 @cached_function
 def T(a):
   return a()
 }}}
 {{{
 sage: %timeit( [T(B(n)) for n in range(10000)])
 100 loops, best of 3: 14.3 ms per loop
 sage: %timeit( [T(A(n)) for n in range(10000)])
 1 loops, best of 3: 25.8 s per loop
 }}}

 Or, with a smaller cache it's still bad (I've cleaned the cache):
 {{{
 sage: %timeit( [T(A(n)) for n in range(100)])
 100 loops, best of 3: 2.22 ms per loop
 sage: %timeit( [T(B(n)) for n in range(100)])
 10000 loops, best of 3: 181 µs per loop
 }}}

 Even for a dictionary of size 10, the trivial hash still causes a 4x
 slowdown.

 A change like this can push code that runs correctly in sage at present to
 a point where running it is not practical. I seriously think there may be
 a user out there that has an application that depends on this code. This
 change would break sage for him in that respect. I am strongly -1 to
 introducing something like that in a release candidate, just before
 release, because we wouldn't catch it.

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