#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:66 darij]:
> Caching these maps relating A to gr(A) on gr(A) was my first idea (and I
think Travis wanted to implement them as conversions), but it conflicts
with Travis's design decision (which is a good one!) to allow overriding
`graded_algebra` with simpler stuff than the default `AssociatedGraded`
construction. Many different complicated algebras A will end up having the
same simple gr(A) (for example, for every universal enveloping algebra A =
U(g) of a Lie algebra g over a field, we have gr(A) \cong S(g)), and gr(A)
is not supposed to "know" anything about A. Overriding
`_element_constructor` of gr(A) would be messy and unscalable.
That suggests that gr(A) should be the simpler object. I'm not sure you
want to go as far as having `gr(A)<A`, but it does strongly suggest you
''don't'' want `A<gr(A)`. You're saying yourself that gr(A) is not
supposed to "know" about A. That implies that `A` is not a construction
parameter for gr(A). Instead, gr(A) should be constructed from basic
parameters that can be retrieved from `A`. Mind you, that doesn't preclude
the existence of an interface function `GradedAlgebra(A)`, but instead of
being a `UniqueRepresentation` class constructor, it would be a factory
function that creates the relevant object from the relevant parameters
from A.
Whether the coercion from A to gr(A) should then be managed by an
"embedding" (that's coercion stored on A) is a different question. There
is a good potential for creating memory leaks via those too.
--
Ticket URL: <http://trac.sagemath.org/ticket/17096#comment:68>
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.