#17096: Implement categories for filtered algebras
-------------------------------------+-------------------------------------
Reporter: tscrim | Owner: tscrim
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.4
Component: categories | Resolution:
Keywords: filtered algebras | Merged in:
Authors: Travis Scrimshaw | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
public/categories/filtered_algebras-17096|
8a747c073e706950d1b14e77458539e126ff0550
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by nbruin):
Replying to [comment:62 darij]:
> @nbruin: I only really digested your post right now. So my changes do
cause memleaks. OK, nothing easier than removing some @cached_method
decorators. But... can you look at the code for `induced_graded_map` and
tell me how to avoid having it re-construct the `other.projection(i)`
method every time I call its return value? (And while the ass. gr. algebra
itself might be UniqueRepresentations, things like the `projection` map
are not unless we hash them.)
Yes, that's tricky. I didn't read the code in detail, but in general I
would expect that with caching maps on objects that use each other as
construction parameters, you do end up with the problematic reference
cycles, rooted in a global cache reference.
If your projection can somehow be obtained as a coercion/conversion you
may be able to lift on the effort that went in there (internally, those
maps drop their reference to the domain now. Since they are normally
cached on the codomain, that seems to usually be enough to break cycles).
I don't have a proof of the following, but conceptually it seems
reasonable to me that you can choose one of the following approaches, but
that mixing them will lead to memory leaks:
- either you express the relation between objects by using one as a
!UniqueRepresentation parameter for the other and you rely entirely on
that relation to tie the objects together
- or you manage the link yourself, by caching stuff on the objects. In
the latter case, you should *not* let any of the globally cached
construction parameters refer to the objects involved. That will usually
mean using !UniqueFactory rather than !UniqueRepresentation, so that you
can process the keys a bit.
I suspect that what we need is that there is a partial ordering on our
globally cached objects, where `A<B` if `A` can occur as part of a
construction cache key for `B`. Having both `A<B` and `B<A` would
naturally lead to a reference cycle and hence a leak.
Furthermore, if `A<B` and A holds a strong reference to B in any form then
there's a leak too.
For instance `QQ` can be a construction parameter of `QQ[x]` because `QQ`
does not refer to `QQ[x]` in any way (the fact that `QQ` coerces into
`QQ[x]` is stored on `QQ[x]`).
In the case here, where I think we have things like
`A=CommutativeAlgebra(QQ,['x','y','z'])` and
`B=GradedCommutativeAlgebra(QQ,['x','y','z'])` it is not clear if we
should have `A<B` or `B<A`. So I think we should have neither (the
constructions above definitely don't need it) and then you're free to
cache on these things in either direction, provided you don't coerce (:-))
the coercion framework into holding a reference cycle.
In hindsight I really think !UniqueRepresentation is a mistaken design
decision. We sort of need it for efficient coercion, though.
--
Ticket URL: <http://trac.sagemath.org/ticket/17096#comment:65>
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.
