#11115: Rewrite cached_method in Cython
------------------------------+---------------------------------------------
Reporter: SimonKing | Owner: jason
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-4.7
Component: misc | Keywords: category cython cache
Author: Simon King | Upstream: N/A
Reviewer: | Merged:
Work_issues: Wait for #9138 |
------------------------------+---------------------------------------------
Comment(by SimonKing):
Replying to [comment:16 nthiery]:
> Replying to [comment:13 SimonKing]:
> Altogether, my only reluctance on this patch is about the addition of
> an attribute to all Sage elements.
I did that for symmetry: Parents and Elements both accept cached methods.
Cached methods only work for an object O if it either accepts attribute
assignment, or provides a special location that is inspected by
`__getattr__`. Otherwise, you need to reconstruct the `CachedMethodCaller`
over and over again, which is a waste of time and also means that, e.g.,
"R.zero_ideal" would always be a ''different'' instance. Thus,
"R.zero_ideal.cache" (which then also can not be stored as an attribute of
R) is always different as well: The cache would break.
But of course, we could argue that cached methods are not of central
importance for elements. So, we may decide to restrict support of cached
methods to those elements that allow for attribute assignment. Then, we
could remove the new `__cached_methods` attribute from
sage.structure.element.Element. I could live with that restricted use of
cached methods for elements.
> This sounds like a non trivial
> increase of the memory footprint for small objects like finite field
> elements.
If no cached methods are used (more precisely: if they are not called),
then `__cached_methods` should just be None (i.e., nothing more but a
pointer, if I understand correctly). So, that's one word per object. If
you do call cached methods then of course you need to store them
somewhere.
> Simon: you are doing way too much good stuff for me to follow!
> Honestly, I feel a bit lost about where to start. Do you mind making a
> prioritized list of patches that need review, say on the category
> roadmap [1]?
My main aim is the letterplace wrapper #7797.
It needs support for ideals in non-commutative rings. That is #11068.
Since there are rings that do not inherit from sage.rings.ring.Ring, we
need to move (or duplicate?) methods from there in
sage.categories.rings.Rings.ParentMethods. That includes cached methods --
but there are rings that do not allow attribute assignment. This is why I
originally opened this patch, #11115 (in the beginning, it was not so much
about performance).
In order to have cached methods (in particular the argspec) appear nicely
in the documentation, we need #9976, which already has a positive review.
Moving stuff from sage.rings.ring.Ring to
sage.categories.rings.Rings.ParentMethods instead of duplicating can only
work if ''all'' rings use the category framework. That's the purpose of
#9138, with a small part already done in #9944.
So, my personal roadmap is simply:
{{{
#9944 #9976
#9138 #11115
#11068
#7797
}}}
After that, I can finally start with my main project: Compute Ext algebras
for finite dimensional path algebra quotients.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/11115#comment:17>
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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
