#16316: cached_function and cached_method for unhashable elements
-------------------------------------+-------------------------------------
Reporter: saraedum | Owner:
Type: enhancement | Status: needs_work
Priority: minor | Milestone: sage-6.3
Component: misc | Resolution:
Keywords: | Merged in:
Authors: Julian Rueth | Reviewers: Peter Bruin
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/saraedum/ticket/16316 | dc37d43b55bfdff5c3c4b93be8c298955d53872e
Dependencies: #16251 | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by saraedum):
Replying to [comment:22 tscrim]:
> Replying to [comment:19 saraedum]:
> > I'm not sure I understand. If p-adics implemented a non-trivial
`__hash__` then this could never be made to be consistent with our current
`==`. The intermediate function creates something with a new `==` which is
then consistent with its `__hash__`. Does this answer your question?
>
> First I'm just making sure it is different than the hash requirements.
By unique you mean this bit of doc:
> {{{
> An implementation must make sure that for elements ``a`` and
``b``, if
> ``a != b``, then also ``a._cache_key() != b._cache_key()``. In
pratice
> this means that the ``_cache_key`` should always include the
``id`` of
> the parent.
> }}}
> whose the contrapositive is if `a._cache_key() == b._cache_key()`, then
`a == b` (assuming that `==` in `p`-adics satisfies `a == b` iff `not (a
!= b)`).
Right.
> I'm good with the new wording
Good.
> (BTW, there's a typo (pratice) and this docstring needs `::`).
Fixed.
> However there is a code smell to me.
Sorry, I'm not familiar with this term.
> The more I think about it, the more I feel what should be done is `==`
be strengthened (i.e. less things compare as equal) and a `__hash__`
method implemented. Yet that did answer my question.
I can understand this point. Strengthening `==` would be a fairly huge
project, affecting a lot of code. Many people would be opposed to this
(including myself).
> - Is there some reason why you didn't `cpdef _cache_key(self)`
This could be changed.
> or make it into a `@lazy_attribute` since it cannot change over the
lifetime of the object?
I do not understand `@lazy_attribute` very well. What would be the
implications of this? If it can't hurt us, then I don't mind changing it.
> - I'm worried about not using the hash for polynomials for caching. I
feel that `_cache_key` should result `self` for every hashable object.
`_cache_key()` is only invoked if the object is unhashable. For most
hashable objects it raises an error.
> For example, this no longer would cache as the same element:
I don't think so. `_cache_key` would never be called in this case.
> So now you're requiring everyone to be ''very'' careful about the parent
an object belongs too.
This is a compromise for elements which are unhashable. This was already
discussed above.
> - I'm pretty sure using the parent's `id` will break pickling with the
cache. So suppose you create parent `A`, store an element `a` in a cache
`C`. Now you pickle and unpickle `a`, `A`, and `C`. The `id` of `A` is
different than before the pickle and unpickling, so we are no longer able
to retrieve `a` from `C`:
I agree. This is a very serious problem.
> I think both of the last two are issues that need to be addressed.
From my point of view, only the last point needs to be addressed.
--
Ticket URL: <http://trac.sagemath.org/ticket/16316#comment:23>
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.
