#16316: cached_function and cached_method for unhashable elements
-------------------------------------+-------------------------------------
Reporter: saraedum | Owner:
Type: enhancement | Status: needs_review
Priority: minor | Milestone: sage-6.3
Component: misc | Resolution:
Keywords: | Merged in:
Authors: Julian Rueth | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/saraedum/ticket/16316 | a65ac8524294fde91e021c39b9f227277ec33d23
Dependencies: #16251 | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by pbruin):
Replying to [comment:9 saraedum]:
> Replying to [comment:8 pbruin]:
> > It seems that the problem really has to do with key comparison in
dictionaries, not with hashing or caching specifically. Given (1)
Python's use of `==` for key comparison and (2) Sage's lenient
implementation of `==` for elements, we basically cannot use Sage elements
as dictionary keys.
> This is not really the topic of the ticket, but I do not agree.
Sorry if this sounded off-topic; I was thinking of the dictionaries used
in caching, but didn't focus on that because I thought my "objections"
were applicable to dictionaries in Sage in general.
I also wanted to avoid focussing on hashing because actually I don't fully
understand what the criteria are for objects to be hashable. The only
thing that is clear to me is that if the "mathematical meaning" can change
over time (e.g. if the object is a list whose length can change, or a
matrix on which you can perform row/column operations), then the object
should not be hashable. But what about ''p''-adic elements? These are
supposedly fixed in time. Why exactly do we want elements of `Zmod(n)`
and `RR` to be hashable but not elements of ''p''-adic fields? Are
''p''-adic fields treated differently because different elements of the
same parent can satisfy `a == b` without being `equal` (e.g. if they have
different precision)? In that case, shouldn't power series also be
unhashable?
> It depends on what you want to do. If you have sufficient control over
which elements are put in the dictionary, then you can use Sage objects.
Sure, but `@cached_function` should also work for user functions, and we
have no control over what kind of arguments the user is going to feed
those. It would not be strange for an unsuspecting user to have some
complicated function of one variable accepting elements of arbitrary
''p''-adic fields, for example. Then the easiest way to cache them would
be to stick `@cached_function` on the function, but that could easily lead
to problems when you don't store the parent, couldn't it?
> Such an operator might be helpful and would really fix trouble with
caching. Then again, when are two objects `equal`? Do their parents have
to be identical? Or just `equal`? It is not clear to me whether there can
be a generic implementation that makes everybody happy.
I would say the only option (for caching purposes) is to make two elements
`equal` only if their parents are identical, otherwise you will get cases
where the cached function returns values in wrong (equal but not
identical) parents. Hence I would translate this hypothetical `equal`
(for elements) in terms of `cache_key` as `x equal y` <=> `parent(x) is
parent(y) and cache_key(x) == cache_key(y)`.
> I have no strong opinion on whether or not to include the parent but I
think it can be more confusing than helpful. Also keys might unnecessarily
be rather large. If your application will only get elements from a single
parent but you store all the data needed to create the extension field
with every element in a cache, that could be really a waste. We could of
course only store `id(parent)`; but I'm not sure whether that is too
extreme.
Actually that was the option I was thinking of; it should be fast and
won't waste too much memory. Alternatively, there could be both an
"internal" `cache_key` (for use with `@cached_method`, where the parent is
known) that does not include the parent `id`, and an "external" one (for
use with `@cached_function`) that does include the parent `id`.
--
Ticket URL: <http://trac.sagemath.org/ticket/16316#comment:10>
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.
