#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 saraedum):
Replying to [comment:10 pbruin]:
> Replying to [comment:9 saraedum]:
> > Replying to [comment:8 pbruin]:
> 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)?
Right, there is no mathematical justification for `p`-adics not being
hashable. It is an implementation detail because their `==` can not be
compatible with `hash`.
> > In that case, shouldn't power series also be unhashable?
Absolutely.
> > 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?
I see. I guess this means that we should at least have that if `a != b`,
then `some_cached_function(a)` should have a chance to be `!=
some_cached_function(b)`.
> > 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)`.
Ok.
> > 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`.
Imho, `@cached_method` and `@cached_function` should not differ in such a
way. Storing the parent's `id` is not a waste of memory and should hardly
lead to any surprises.
I'll push a new commit which implements the inclusion of the parent.
Thanks for joining this discussion btw.
--
Ticket URL: <http://trac.sagemath.org/ticket/16316#comment:11>
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.
