#16353: A cached_function with selective memory
-------------------------+-------------------------------------------------
Reporter: | Owner:
ncohen | Status: needs_review
Type: | Milestone: sage-6.3
enhancement | Resolution:
Priority: major | Merged in:
Component: | Reviewers:
performance | Work issues:
Keywords: | Commit:
Authors: | 7eb8f900f1a143c6cc85b9382a365b57a9c42ecc
Nathann Cohen | Stopgaps:
Report Upstream: N/A |
Branch: |
u/ncohen/16353 |
Dependencies: |
-------------------------+-------------------------------------------------
Comment (by ncohen):
> You are right in noting that. You could of course document that the
result returned shouldn't be modified (but instead copied if modification
is needed), and that is probably the most efficient solution for an
internal routine, where the caller can then make a copy only when
necessary. And indeed, you can enforce (one level at the time) by using
tuples.
It is not an internal routine.
> If you want an always-safe-to-mutate result, you would always need to
*copy* into cache (or copy the result once it's written into the cache),
which is not what is proposed on this ticket. In fact, copying is a
complicated, data type dependent operation (think tuple of lists, for
instance -- how deep do you have to go with copying?)
I repeat : I do *NOT* want to cache this output.
> It seems to me that this additional motivation for using the decorator
provides another argument *against* the utility and wisdom of the proposed
decorator for producing clear, readable, and maintainable code.
Understand what you want to understand. I am telling you that I will have
to implement 4 times the same code in different functions, and that all my
problems could be solved with the clear and understandable lines that this
branch implements, at absolutely no cost for anybody else.
The code will less clear because of that, the design files will contain
code dedicated to caching that does not belong there, and of course I will
be implementing manually what could be done by a decorator.
Waste of time.
Nathann
--
Ticket URL: <http://trac.sagemath.org/ticket/16353#comment:37>
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.
