#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|
096538121130679a55b971d3d3a5626e94b157a5
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by tscrim):
Replying to [comment:43 darij]:
> Care to explain this? I'm still a newbie to memory handling, so I might
be missing more of the context than you expect. My worry was that every
time `A.graded_algebra()` is called (and it will be called a lot, say,
from the `to_graded_conversion` and `projection` methods), a new instance
of this algebra is created, which takes time and space and might require
additional work to make these instances coerce to each other nicely (I
guess they will do so themselves automatically, but e.g. their polynomial
rings might not).
See Nils comment for the memory. Short version is you get a reference loop
`A -> grA` and `grA -> A` such that `A` is stored as a global strong
reference (making it uncollectible). I opted to make the output of
`graded_algebra` be a non-`cached_method` as the `UniqueRepresentation` of
`AssociatedGradedAlgebra` will make sure it's extremely rarely (re)created
(and because I need the filtered algebra to do the computations, so it has
to be part of the construction data). As this will likely be what gets
created, we don't have to worry about this (and most parents will end up
being UR's). If the user creates a non-UR parent for the assoc. gr., then
they have to override `graded_algebra` anyways and can make it a cached
method.
> Also, should I then explain in the doc that everybody who overshadows
`graded_algebra` must also overshadow `projection`, `to_graded_conversion`
and `from_graded_conversion`?
I don't think these methods would need to be overwritten as they are
completely generic.
> Great -- as long as this magic doesn't force every algebra which happens
to be filtered as a module to automatically be considered a filtered
algebra.
I think that gets into the issue (and is related with John's comment) with
what do for filtrations in general. I want to use `degree` for the
filtration parameter so we don't have to duplicate code, it's natural for
graded modules/algebras, and which filtration component is not well-
defined (most elements belong to multiple, possibly infinite, F,,i,,
components). Overall, we will need a framework for construction of general
filtrations, but I don't think we can do that at the category level. What
will probably be best (a quick thought) is to have a method `filtration`
which returns the filtration of the module/algebra as a `Family` of
submodules indexed by `I`. However we will still need a method `degree` to
be computationally quick. This would allow filtrations different from the
grading in a way and perhaps we could add a method to the graded
categories such as `filtration_degree` which by default returns the usual
degree. Anyways, I think about more later.
--
Ticket URL: <http://trac.sagemath.org/ticket/17096#comment:46>
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.
