#15931: Implement a proper hash function for (combinatorial) free module
elements
-------------------------------------+-------------------------------------
Reporter: nthiery | Owner:
Type: defect | Status: needs_review
Priority: major | Milestone: sage-6.2
Component: linear algebra | Resolution:
Keywords: | Merged in:
Authors: Nicolas M. Thiéry | Reviewers: Florent Hivert
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/nthiery/ticket/15931 | e8fe5eb8943debdb457c38d3264167d66e7b2b14
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by SimonKing):
Replying to [comment:4 nthiery]:
> It's almost an order of magnitude faster (more with larger elements),
assuming we often recompute the hash value of elements.
Glad to see that the decorator is useful on magical Python methods (by the
way, `__len__` and so on can now be cached as well).
> Do we want to do this?
I guess I am biased... ;-) (take that as "yes, from my viewpoint")
It reminds me, though, that I should investigate a potentially nasty
detail. Assume that @cached_method is applied to the hash. Then an
instance `O` is created, that has the hash `h1`. Then we save `O`. Later,
the `__hash__` is changed, so that a newly created copy of `O` should have
hash `h2!=h1`. Would it be the case that ''reloading'' `O` from the old
pickle still has `hash(O)==h1`, i.e., would the old hash value be part of
the pickle? This would be bad.
--
Ticket URL: <http://trac.sagemath.org/ticket/15931#comment:5>
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.
