#18044: Implement categories for super algebras/modules
-------------------------------------+-------------------------------------
Reporter: tscrim | Owner: tscrim
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.6
Component: categories | Resolution:
Keywords: super | Merged in:
Authors: Travis Scrimshaw | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
public/categories/super_categories-18044|
0ce1cad1332ec34909c4baa2761307a3bd205ef8
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by darij):
Replying to [comment:11 tscrim]:
> So we could do an explicit override of the `SuperHopf`'s super category
(at least, this is probably one of the very few instances where a super
object is different notation from the graded).
Sorry, I just don't like this whole paradigm where a category liberally
makes assumptions that the subcategory has to override if they are not
satisfied. The category framework was created to mirror the mathematical
structure of algebraic categories (or so I have been told).
Mathematically, there is no reason why a superX should canonically be an
X; the fact that this holds for many of the standard Xes (algebras,
modules, etc.) is not inherent to the notion of "super"ness but to these
Xes, so it shouldn't be reflected in any automatic inheritance. Does the
way you implemented `Super` require `SuperX` to derive from `X`?
--
Ticket URL: <http://trac.sagemath.org/ticket/18044#comment:12>
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.
