Opened 4 years ago

Closed 4 years ago

#18044 closed enhancement (fixed)

Implement categories for super algebras/modules

Reported by: tscrim Owned by: tscrim
Priority: major Milestone: sage-6.9
Component: categories Keywords: super, sd67
Cc: nthiery, darij Merged in:
Authors: Travis Scrimshaw Reviewers: Darij Grinberg
Report Upstream: N/A Work issues:
Branch: 16a3791 (Commits) Commit: 16a3791a26e665843d0b9357a0bd56f4daf88881
Dependencies: #18174 Stopgaps:

Description

After some design discussion, a proposal for an implementation is to be a subcategory of Graded algebras/modules whose default even/odd considers the given grading as being ZZ / 2 ZZ compatible. Thus it will have the following methods:

  • is_even()
  • is_odd()
  • is_even_odd()

The API will be the user defines a degree method which is then called by is_even_odd() and taken mod 2. Therefore if the user wants to have a special grading group, then the user can override is_even_odd() to translate that into 0 or 1. The hook of is_even_odd also allows the user to change the super behavior away from the grading group (which will get used in #17096).

Change History (31)

comment:1 Changed 4 years ago by tscrim

  • Branch set to public/categories/super_categories-18044
  • Commit set to cd6d21aa19660d5b60074d5e5299310e6e27d626
  • Status changed from new to needs_review

New commits:

cd6d21aCreated super categories for algebras and modules.

comment:2 Changed 4 years ago by darij

+ def Super(self, base_ring=None):
+ r"""
+ Return the subcategory of the super objects of ``self``.

Is this really a subcategory? Super Lie algebras are not Lie algebras and cannot be reasonably made into such short of taking the even part...

comment:3 Changed 4 years ago by tscrim

Good point (this is different than Graded, which is where I copied things from). Think we should just replace the word "sub" with "associated"? If so, I can go make this change (in about 2 hours).

comment:4 follow-up: Changed 4 years ago by darij

I'd just say "Return the super-analogue of self" (the word "analogue" is a bit weasel, but I think it's better to err on this side). In general, there should be a canonical embedding from C into C.Super(), not the other way round.

What do you mean by "Same as :meth:Graded"?

comment:5 in reply to: ↑ 4 Changed 4 years ago by tscrim

Replying to darij:

I'd just say "Return the super-analogue of self" (the word "analogue" is a bit weasel, but I think it's better to err on this side). In general, there should be a canonical embedding from C into C.Super(), not the other way round.

It's more of there is not a forgetful functor from C.super() to C, but I'll make this change.

What do you mean by "Same as :meth:Graded"?

Meaning I copied it. <.< >.>

comment:6 Changed 4 years ago by git

  • Commit changed from cd6d21aa19660d5b60074d5e5299310e6e27d626 to 0ce1cad1332ec34909c4baa2761307a3bd205ef8

Branch pushed to git repo; I updated commit sha1. New commits:

3d33730Merge branch 'develop' into public/categories/super_categories-18044
0ce1cadChanging the wording of the Super method.

comment:7 Changed 4 years ago by tscrim

I've made the change. Although actually, forgetting the "super" doesn't change the multiplication, just removes the notion of supercommuting elements and the degree. So there is a forgetful functor at least, right (or am I overthinking things)?

comment:8 Changed 4 years ago by darij

Forgetting the grading on a superalgebra gives you an algebra, yes. But forgetting the grading on a Lie superalgebra does not give you a Lie algebra; it gives something weird and unnamed. So forgetful functors should only exist in specific categories.

comment:9 Changed 4 years ago by tscrim

True, but I think for now we can live with the slight abuse since there are not plans currently (at least by me) to implement Lie superalgebras. Then again, IDK how much of the code I've written wouldn't work in the category for Lie superalgebras. ehh...I think we can cross that bridge if/when that's an issue.

comment:10 Changed 4 years ago by darij

Sorry but the assumption that "super X are graded X" (or just "super X are X") is fundamentally wrong. The longer we keep it in, the harder it will be to cross that bridge. It already causes wrong results:

sage: C = HopfAlgebras(QQ).Super()
sage: C.super_categories()
[Category of hopf algebras over Rational Field,
 Category of super algebras over Rational Field]

Super Hopf algebras are not Hopf algebras. In a Hopf algebra, (xy)_{(1)} \otimes (xy)_{(2)} = x_{(1)} y_{(1)} \otimes x_{(2)} y_{(2)} (using sumfree Sweedler notation), while in a super Hopf algebra, (xy)_{(1)} \otimes (xy)_{(2)} = (-1)^{\deg y_{(1)} \deg x_{(2)}} x_{(1)} y_{(1)} \otimes x_{(2)} y_{(2)} .

In other news: In the lift_module_morphism method for Clifford algebras, did you really mean Graded in

        return Cl.module_morphism(on_basis=f, codomain=self,
                                  category=AlgebrasWithBasis(self.base_ring()).Graded())

(and not Super)?

comment:11 follow-up: Changed 4 years ago by tscrim

Then I guess we need to change the default super categories thingy and just be explicit about things. So then the category hierarchy should be

SuperHopf    GradedHopf
    |           |
SuperAlg      Hopf
       \     /
         Alg

right? 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).

comment:12 in reply to: ↑ 11 Changed 4 years ago by darij

Replying to 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?

comment:13 Changed 4 years ago by tscrim

Currently yes, but I'm going to change it so that you have to explicitly set X to be supercategory of superX.

comment:14 Changed 4 years ago by darij

Thank you!

comment:15 Changed 4 years ago by git

  • Commit changed from 0ce1cad1332ec34909c4baa2761307a3bd205ef8 to b29650b87b103a465d66de189182a0e7dcf4fde9

Branch pushed to git repo; I updated commit sha1. New commits:

b29650bMade it so you must explicitly designate graded as a super category

comment:16 follow-up: Changed 4 years ago by tscrim

I'm not happy with this because of how certain things in the category hierarchy are respected, even in this new version. In particular:

sage: C = HopfAlgebras(ZZ).WithBasis().Super(); C
Category of super hopf algebras with basis over Integer Ring
sage: sorted(C.super_categories(), key=str)
[Category of hopf algebras with basis over Integer Ring,
 Category of super algebras over Integer Ring,
 Category of super algebras with basis over Integer Ring]

I don't know a way around this currently...

However I'm starting to wonder if this is what we want. If we want two notions of super, the first is via a functorial construction for things like modules and algebras (and rings once the graded versions get implemented), and for other things if we want the Super call to go to a Category_over_base_ring subclass. Mainly the first examples satisfy the conditions of the regressive covariant functorial construction, but the others, like Hopf and Lie algebras, don't. Doing things this way also seem like they will simplify the implementation as a fringe benefit. Thoughts (inc. from Nicolas)?

comment:17 in reply to: ↑ 16 Changed 4 years ago by nthiery

Replying to tscrim:

(inc. from Nicolas)?

I don't have the big picture at this point. Let's discuss this in Montreal!

comment:18 Changed 4 years ago by tscrim

  • Dependencies set to #18174

#18174 will simplify this a bit.

comment:19 Changed 4 years ago by git

  • Commit changed from b29650b87b103a465d66de189182a0e7dcf4fde9 to 7554dbda3721d66fb582ab3bf22c1d3c577b7934

Branch pushed to git repo; I updated commit sha1. New commits:

7554dbd1 step forward, 2 steps back.

comment:20 Changed 4 years ago by git

  • Commit changed from 7554dbda3721d66fb582ab3bf22c1d3c577b7934 to caada136601a6af26a7c66ec417a0180b00b1812

Branch pushed to git repo; I updated commit sha1. New commits:

caada13Going all the way to the finish line like a superstar.

comment:21 Changed 4 years ago by tscrim

  • Keywords sd67 added

comment:22 Changed 4 years ago by git

  • Commit changed from caada136601a6af26a7c66ec417a0180b00b1812 to 26859cb85f383cfd73db9702c6cf20b94f2a808f

Branch pushed to git repo; I updated commit sha1. New commits:

26859cbmanual merge with sage 6.7.beta1

comment:23 Changed 4 years ago by git

  • Commit changed from 26859cb85f383cfd73db9702c6cf20b94f2a808f to 60518658bf6575db0a12a7fce0b863dffea8d9cb

Branch pushed to git repo; I updated commit sha1. New commits:

6051865add a doctest which hopefully works (hard to check while compiling)

comment:24 Changed 4 years ago by git

  • Commit changed from 60518658bf6575db0a12a7fce0b863dffea8d9cb to b91cd828945a4668938298ef741769ce64f909a3

Branch pushed to git repo; I updated commit sha1. New commits:

570bc49Merge branch 'public/categories/super_categories-18044' into 6.9.b1
b91cd82trac #18044 correct one typo in the doc

comment:25 Changed 4 years ago by git

  • Commit changed from b91cd828945a4668938298ef741769ce64f909a3 to 057933782566ba05423d302fe8fae82276238edc

Branch pushed to git repo; I updated commit sha1. New commits:

7fd1df2Merge branch 'public/categories/super_categories-18044' of trac.sagemath.org:sage into public/categories/super_categories-18044
0579337Some reviewer tweaks and doc additions.

comment:26 Changed 4 years ago by git

  • Commit changed from 057933782566ba05423d302fe8fae82276238edc to aec22cc54dee46aceaa315a96905059927ad1ea4

Branch pushed to git repo; I updated commit sha1. New commits:

aec22ccAdded one more test.

comment:27 Changed 4 years ago by darij

LGTM now; thanks for the commit!

For posterity: There are design issues that I don't fully like, but that are standard for Sage.

comment:28 Changed 4 years ago by tscrim

  • Milestone changed from sage-6.6 to sage-6.9
  • Reviewers set to Darij Grinberg
  • Status changed from needs_review to positive_review

comment:29 Changed 4 years ago by git

  • Commit changed from aec22cc54dee46aceaa315a96905059927ad1ea4 to 16a3791a26e665843d0b9357a0bd56f4daf88881
  • Status changed from positive_review to needs_review

Branch pushed to git repo; I updated commit sha1 and set ticket back to needs_review. New commits:

16a3791Marked a doctest as indirect doctest.

comment:30 Changed 4 years ago by tscrim

  • Status changed from needs_review to positive_review

One test should have been marked as # indirect doctest.

comment:31 Changed 4 years ago by vbraun

  • Branch changed from public/categories/super_categories-18044 to 16a3791a26e665843d0b9357a0bd56f4daf88881
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.