#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|
b29f67e46e18721313330d3a6e116cf3df2eaf8e
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by tscrim):
@darij
I really don't like the restrictions of this contract you want to impose;
it's too restrictive. It should not take a new *class* to do something
which is mathematically trivial (by our current implementation of an
implicit filtration). IMO, the better way to do things is to implement
additional methods in the category for the projections (similar to
`truncate`) since the methods only use the `degree` methods. Also I think
requesting a conversion for the returned object `graded_algebra` is fine,
but not making it a requirement.
As for the induced morphisms, we might actually want to make the method a
functor object. This I think will solve many of the issues you want to do
with contracts.
All I wanted with the `AssociatedGradedAlgebra` class was to prove a
generic implementation do to the computations and the method
`graded_algebra` just to return an object which *is* the associated graded
algebra. My implementation of `AssociatedGradedAlgebra` just happens to
have the need for the extra data.
Every `FilteredAlgebrasWithBasis` is a subcategory of
`FilteredModulesWithBasis`. I'm okay with this move. If we use methods
(instead of contracts) at the `FilteredModules` level (perhaps
`WithBasis`), then we could implement a very lightweight class for this,
but I'm worried about having the extra burden of methods that only are
really useful for modules (and get superseded for "better" named methods).
Although if we use a functor to do the construction, then I feel like we
get away from all of it.
However I feel that much of this should be done on followup ticket(s) as
getting the basic framework into Sage can be split and doesn't need the
full features to be useful.
@jhpalmieri
I'll make those changes. However we can't get a descending filtration
unless the grading set can be negated. As for algebras that are both
filtered and graded, it's the same issue as when an algebra has 2 natural
gradings (as we use `degree` for both filtration and grading). Although as
things evolve and the filtration can be generalized from using `degree`,
this can be rectified. For now, you have to choose the "best" one for
`degree` (or have it be an optional arg like how I'm doing for Clifford
algebras).
@nbruin
Will fix. Forgot that the categories are not collectible.
--
Ticket URL: <http://trac.sagemath.org/ticket/17096#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.
