Signed tensor product for graded algebras, coalgebras, etc.

[jhpalmieri]

Goal: implement a signed version of (co)product structure on tensor products of graded (or super) (co)algebras. We should be able to define superalgebras A and B and specify that when they are tensored together, the product structure has this property

(x1 tensor y1) (x2 tensor y2) = (-1)^{(deg y1) (deg x2)} (x1 x2 tensor y1 y2).

(And similarly for coalgebras.) The underlying algebras need not be graded commutative themselves. The Steenrod algebra is one use case – it is noncommutative, but we definitely want this property when defining the product on its tensor square.

CC: @tscrim @nthiery @cnassau

Component: categories

Keywords: fpsac2019

Author: John Palmieri, Travis Scrimshaw

Branch/Commit: ccccd8a

Reviewer: Travis Scrimshaw, John Palmieri, Darij Grinberg

Issue created by migration from https://trac.sagemath.org/ticket/25603

[jhpalmieri]

comment:1

See https://groups.google.com/forum/#!topic/sage-devel/8broUYQ0p7c/discussion for one bug which could be fixed by implementing this.

[jhpalmieri]

Branch: u/jhpalmieri/graded-tensor

[sagetrac-git]

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

bacbe13

trac 25603: signed tensor product for super modules, algebras, coalgebras

[sagetrac-git]

Commit: bacbe13

[jhpalmieri]

comment:5

Here's an attempt.

[sagetrac-git]

Changed commit from bacbe13 to bf48b87

[sagetrac-git]

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

bf48b87

trac 25603: allow a sign in _test_antipode for Hopf algebras.

[jhpalmieri]

comment:7

Coincidentally, Christian Nassau found a bug in the antipode formula for the Steenrod algebra. Fixing that bug led me to realize that _test_antipode should allow for a sign in the graded/super case.

If this ticket doesn't get done soon, I'll split off that fix into a separate ticket. This won't be as good, because it will involve disabling _test_antipode for the Steenrod algebra.

[tscrim]

comment:8

Unfortunately I probably won't get to this for a few days (I will be on a trip across Europe: 4 cities in 5 days). It will be basically at the top of my todo list when I get to the Sage Days in Zaragoza.

[jhpalmieri]

comment:9

A few days would be great. If it starts to take months, then I'll consider other options for the Steenrod algebra bug.

[jhpalmieri]

comment:10

Aside from more important things (like the whole approach taken here), one question to consider is the name of the axiom, and also how it is printed. I am not particularly happy with the current version.

[tscrim]

comment:11

I'm not too happy with how things look right now either. I'm not sure what the code is trying to tell me, but I am reading it like something does need to be changed in the approach here. I think you should reimplement product_on_basis for the new subcategory (let the MRO handle the choice). I will try to find some time to ponder about this on my upcoming flight.

My quick thoughts on naming: SignTwistedTensor, or a generic TwistedTensor with a specific implementation for signs, or TensorTwistedWithSign.

Nicolas, we would appreciate any thoughts you have on this matter. (Otherwise, I will be forced to corner you at ICERM in a month! :P)

[darijgr]

comment:12

TensorGradedWithSign should not be an axiom! It changes the behavior of certain methods; axioms lead to default inheritance, so (in theory) every method built for an algebra would have to be overloaded for a superalgebra in order not to give wrong results.

The proper way should be defining something like SuperModule, SuperAlgebra, etc. (over a non-graded base ring at first). I'm wondering if we perhaps should define the whole braided zoo right away, seeing that it's a wide field open for computation -- but I'm not quite sure how to go about doing this, seeing that a braiding isn't fully the responsibility of each of the two modules.

[jhpalmieri]

comment:13

Replying to @darijgr:

TensorGradedWithSign should not be an axiom! It changes the behavior of certain methods; axioms lead to default inheritance, so (in theory) every method built for an algebra would have to be overloaded for a superalgebra in order not to give wrong results.

I don't understand what you mean, probably because I don't understand the category theory framework in Sage, which I am going to blame on the state of the documentation. What is the role of axioms vs. categories vs. Python classes? In my experience, by the way, inheritance with axioms doesn't always work the way you might want, because it doesn't override methods which are inherited from other Python classes.

In this particular situation, only methods which deal with tensor products should be affected, so I think you're overstating things when you talk about potentially having to change every method for algebras.

The proper way should be defining something like SuperModule, SuperAlgebra, etc. (over a non-graded base ring at first). I'm wondering if we perhaps should define the whole braided zoo right away, seeing that it's a wide field open for computation -- but I'm not quite sure how to go about doing this, seeing that a braiding isn't fully the responsibility of each of the two modules.

Categories for SuperModules and SuperAlgebras already exist in Sage, so I'm not sure what you mean by the first sentence. Also, are you suggesting that for superalgebras (for example), the signed tensor product should be the default behavior? I think in the past you have argued against this being the default behavior in the graded case.

Implementing some sort of braiding sounds great, but not for this ticket, and not as a prerequisite for this ticket.

[darijgr]

comment:14

Yeah, that braiding suggestion was probably overkill, sorry.

And if we have SuperAlgebras and SuperModules, then we should use them, not push another axiom on Algebras.

I don't think that "only methods which deal with tensor products should be affected"; tensors can be multiplied back in a Hopf algebra, and various constructions in a Hopf algebra involve delta-ing out, messing with the tensors, and then multiplying back. They all slightly change if the algebra becomes super.

[jhpalmieri]

comment:15

Replying to @darijgr:

Yeah, that braiding suggestion was probably overkill, sorry.

And if we have SuperAlgebras and SuperModules, then we should use them, not push another axiom on Algebras.

So should SuperAlgebras (or at least WithBasis) have this sign by default when taking tensor products? Or do we need a new category?

And I'm still interested in why a category rather than an axiom. Your first post seemed to be operating from some set of principles, but I don't know what those principles are or where they are documented. I would be happy to hear more.

I don't think that "only methods which deal with tensor products should be affected"; tensors can be multiplied back in a Hopf algebra, and various constructions in a Hopf algebra involve delta-ing out, messing with the tensors, and then multiplying back. They all slightly change if the algebra becomes super.

Not in characteristic 2 :p

They also don't change unless you are (implicitly or explicitly) interchanging tensor factors. I'm curious about mathematical examples of such constructions. The only examples that I can find in the actual Sage category code are the product for tensor products of algebras and _test_antipode for Hopf algebras. (There should also be a coproduct for tensor products of coalgebras, but it apparently hasn't been implemented.)

[jhpalmieri]

comment:16

On my computer, I created a branch in which I just imposed the sign for super modules/algebras/Hopf algebras with basis. I get one doctest failure for Clifford algebras (_test_antipode fails because ValueError: element is not homogeneous), which brings me back to one of my questions: should SuperAlgebrasWithBasis impose the Koszul sign convention?

[jhpalmieri]

comment:17

In fact, some_elements is broken for exterior algebras:

sage: E.<x,y,z> = ExteriorAlgebra(QQ)
sage: E.some_elements()
[x^y + 2*x + 3*y + 1]

"x^y"??? I don't know how TestSuite(E).run() passes in vanilla Sage. I've opened up #25630 for this.

By the way, exterior algebras provide another instance of the bug referenced in comment:1:

sage: E.<x,y,z> = ExteriorAlgebra(QQ)
sage: x**2
0
sage: x.coproduct()
1 # x + x # 1
sage: (x.coproduct())**2 # should be 0
2*x # x

[sagetrac-git]

Changed commit from bf48b87 to 924a106

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

924a106

trac 25603: include sign in tensor product for super algebras and Hopf algebras

[sagetrac-git]

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

109f3bc

trac 25603: remove comment about super Hopf algebras

[sagetrac-git]

Changed commit from 924a106 to 109f3bc

[sagetrac-git]

Changed commit from 109f3bc to 1ac4be4

[sagetrac-git]

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

1ac4be4

trac 25603: make sure the TestSuite for some exterior algebras

[darijgr]

comment:22

So should SuperAlgebras (or at least WithBasis) have this sign by default when taking tensor products? Or do we need a new category?

Probably SuperAlgebras should have this sign by default. Does anything speak against it?

And I'm still interested in why a category rather than an axiom. Your first post seemed to be operating from some set of principles, but I don't know what those principles are or where they are documented. I would be happy to hear more.

From what I believe, an extra axiom spawns a subclass. Thus, if "super" is an axiom, then every superalgebra will be an algebra. Which would be OK if we would implement all the functionality that differs between super- and non-super-algebras as separate methods ("super-tensor product", "supercommutator", "superbialgebra", "superconvolution" and whatnot) rather than overriding standard methods. But if we override standard methods, we are creating a minefield. You are right -- the currently implemented generic Hopf-algebra methods (minus the bialgebra axiom check) mostly survive a superization (and even braiding) without changes (e.g., the recursive formula for an antipode in a connected graded bialgebra doesn't change if the word "super" gets added), but there is no real guarantee that it will stay so for the more complicated methods we will eventually add.

[jhpalmieri]

comment:79

New doctest failures in clifford_algebra.py and super_modules_with_basis.py, with very long tracebacks, but the punchline seems to be

    TypeError: Cannot create a consistent method resolution
    order (MRO) for bases FilteredModules.subcategory_class, VectorSpaces.subcategory_class

[sagetrac-git]

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

8ab6815

Adding more placeholder classes to fix MRO resolution issues.

[sagetrac-git]

Changed commit from d29a86d to 8ab6815

[tscrim]

comment:81

Sorry about that; I thought I had ran all the tests in the categories folder. Thank you for fixing the remaining stuff from my changes.

I fixed the MRO issue by adding some more placeholder classes for graded/filtered vector spaces. This fixes #15475 and #20896.

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

0c59b50

Adding more placeholder classes to fix MRO resolution issues.

[sagetrac-git]

Changed commit from 8ab6815 to 0c59b50

[jhpalmieri]

comment:83

I think this looks good, but I'm going to keep banging away at it for a few days.

A few questions:

• This is probably overkill, but in characteristic 2, would it make sense to automatically convert super -> graded (over Z/2), since there are no signs involved? Probably not worth it, but in characteristic 2, exterior algebras are honest Hopf algebras, as is the mod 2 Steenrod algebra.
• Why this asymmetry?

sage: AlgebrasWithBasis(QQ).Super().super_categories()
[Category of graded algebras with basis over Rational Field,
 Category of super algebras over Rational Field,
 Category of super modules with basis over Rational Field]
sage: CoalgebrasWithBasis(QQ).Super().super_categories()
[Category of super modules with basis over Rational Field,
 Category of coalgebras with basis over Rational Field,
 Category of super coalgebras over Rational Field]

Should "Category of graded coalgebras with basis ..." be among the super categories in the second case, rather than just "Category of coalgebras with basis ..."?

[jhpalmieri]

comment:84

Replying to @tscrim:

I fixed the MRO issue by adding some more placeholder classes for graded/filtered vector spaces. This fixes #15475 and #20896.

Are those actually still problems? I tried the examples in the ticket descriptions, and they work in vanilla 8.9.beta2. An example from one of darij's comments is indeed fixed by this, I think.

[sagetrac-git]

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

7a1ed44	Adding forgotten extra_super_categories.
a9230b4	Bring cocommutative higher in the axiom list (for any relevant printing).
ccccd8a	Pyflakes and added supercocommutative to axiom whitelist.

[sagetrac-git]

Changed commit from 0c59b50 to ccccd8a

[tscrim]

Reviewer: Travis Scrimshaw, John Palmieri

[tscrim]

comment:86

Replying to @jhpalmieri:

I think this looks good, but I'm going to keep banging away at it for a few days.

Thank you.

• This is probably overkill, but in characteristic 2, would it make sense to automatically convert super -> graded (over Z/2), since there are no signs involved? Probably not worth it, but in characteristic 2, exterior algebras are honest Hopf algebras, as is the mod 2 Steenrod algebra.

Perhaps this would not be bad to add, but I am a little worried about mucking with the extra_super_categories() too much at this point. So I think it would be good for a followup ticket as I might have already rolled too much into here (i.e., the (super)(co)commutative axioms).

• Why this asymmetry?

sage: AlgebrasWithBasis(QQ).Super().super_categories()
[Category of graded algebras with basis over Rational Field,
 Category of super algebras over Rational Field,
 Category of super modules with basis over Rational Field]
sage: CoalgebrasWithBasis(QQ).Super().super_categories()
[Category of super modules with basis over Rational Field,
 Category of coalgebras with basis over Rational Field,
 Category of super coalgebras over Rational Field]

Should "Category of graded coalgebras with basis ..." be among the super categories in the second case, rather than just "Category of coalgebras with basis ..."?

That was a bug. Good catch. I forgot to add the extra_super_categories for that class.

[tscrim]

comment:87

Replying to @jhpalmieri:

Replying to @tscrim:

I fixed the MRO issue by adding some more placeholder classes for graded/filtered vector spaces. This fixes #15475 and #20896.

Are those actually still problems? I tried the examples in the ticket descriptions, and they work in vanilla 8.9.beta2. An example from one of darij's comments is indeed fixed by this, I think.

Curiously enough with this branch, I am actually getting back the behavior on that comment. So something very subtle is going on, but the MRO issue seems to still be resolved. The reason why I mentioned those tickets was because the MRO issue reminded me of them, but that seems to be a red herring. Curious...

[darijgr]

comment:88

The can of superworms has just been reopened on MathOverflow: https://mathoverflow.net/questions/335889/hopf-structure-on-the-universal-enveloping-of-a-super-hopf-algebra

Note that Bugs Bunny, in his answer, does something very similar to what you guys have agreed on (I think?): use different symbols \otimes and \otimes^{sup} for tensors and super-tensors, even at the level of elements.

[darijgr]

comment:89

--- a/src/sage/algebras/clifford_algebra.py
+++ b/src/sage/algebras/clifford_algebra.py
-        cat = HopfAlgebrasWithBasis(R).Super().FiniteDimensional()
+        cat = HopfAlgebrasWithBasis(R).FiniteDimensional().Supercommutative().Supercocommutative()

Are you sure it shouldn't be "HopfSuperAlgebrasWithBasis(R)"?

--- a/src/sage/algebras/steenrod/steenrod_algebra.py
+++ b/src/sage/algebras/steenrod/steenrod_algebra.py
-        from sage.categories.graded_hopf_algebras_with_basis import GradedHopfAlgebrasWithBasis
+        from sage.categories.super_hopf_algebras_with_basis import SuperHopfAlgebrasWithBasis

I see the existence of a Z-grading (as opposed to just as a Z/2-grading) is getting lost here. Is there a way to preserve it? A GradedSuperHopfAlgebrasWithBasis category perhaps? Or are we not having anything that can make use of the grading to begin with?

(Eventually, gradings will be very useful, as they allow you to do linear algebra when the graded parts are finite-dimensional.)

--- a/src/sage/categories/coalgebras.py
+++ b/src/sage/categories/coalgebras.py
+    class Cocommutative(CategoryWithAxiom_over_base_ring):
+        """
+        Category of cocommutative coalgebras.
+        """

Is this class meant to be completely empty as it currently stands?

+        class SubcategoryMethods:
+            @cached_method
+            def Supercocommutative(self):
+                r"""
+                Return the full subcategory of the supercocommutative
+                objects of ``self``.

This seems to be in the Coalgebras class. But it only makes sense for supercoalgebras. Are we trying to cause spooky action at a distance here?

--- a/src/sage/categories/graded_algebras_with_basis.py
+++ b/src/sage/categories/graded_algebras_with_basis.py
+    class SignedTensorProducts(SignedTensorProductsCategory):
+        """
+        The category of algebras with basis constructed by signed tensor
+        product of algebras with basis.
+        """

The word "super", or at least "graded", should probably fall somewhere here.

Can you add doctests verifying that SuperBialgebras are not a subcat of Bialgebras, supercommutative superalgebras are not commutative algebras, and same for supercoalgebras?

[jhpalmieri]

comment:90

Replying to @darijgr:

I can't answer any of the design questions, so I hope Travis will respond, too.

--- a/src/sage/algebras/clifford_algebra.py
+++ b/src/sage/algebras/clifford_algebra.py
-        cat = HopfAlgebrasWithBasis(R).Super().FiniteDimensional()
+        cat = HopfAlgebrasWithBasis(R).FiniteDimensional().Supercommutative().Supercocommutative()

Are you sure it shouldn't be "HopfSuperAlgebrasWithBasis(R)"?

The "Supercommutative" and "Supercocommutative" axioms imply "Super" Hopf algebra, so is this necessary?

--- a/src/sage/algebras/steenrod/steenrod_algebra.py
+++ b/src/sage/algebras/steenrod/steenrod_algebra.py
-        from sage.categories.graded_hopf_algebras_with_basis import GradedHopfAlgebrasWithBasis
+        from sage.categories.super_hopf_algebras_with_basis import SuperHopfAlgebrasWithBasis

I see the existence of a Z-grading (as opposed to just as a Z/2-grading) is getting lost here. Is there a way to preserve it? A GradedSuperHopfAlgebrasWithBasis category perhaps? Or are we not having anything that can make use of the grading to begin with?

Maybe a graded object should have a method or attribute grading_group (or whatever you want to call it). I'm not sure how else you would convey this information, because GradedSuperHopfAlgebras... is redundant: super implies graded, and "graded" should make no assumptions about what the grading group is. You could have GradedConnectedSuperHopfAlgebras... because graded + connected implies a Z-grading (at least to me: it doesn't mean "connected as a Hopf algebra" + "graded as a (super) Hopf algebra").

(Eventually, gradings will be very useful, as they allow you to do linear algebra when the graded parts are finite-dimensional.)

At least with the Steenrod algebra, there is a method homogeneous_component which takes a degree as input and returns the finite dimensional vector space, with basis, for the component in that degree.

--- a/src/sage/categories/coalgebras.py
+++ b/src/sage/categories/coalgebras.py
+    class Cocommutative(CategoryWithAxiom_over_base_ring):
+        """
+        Category of cocommutative coalgebras.
+        """

Is this class meant to be completely empty as it currently stands?

+        class SubcategoryMethods:
+            @cached_method
+            def Supercocommutative(self):
+                r"""
+                Return the full subcategory of the supercocommutative
+                objects of ``self``.

This seems to be in the Coalgebras class. But it only makes sense for supercoalgebras. Are we trying to cause spooky action at a distance here?

I tried deleting this and got a few doctest failures:

**********************************************************************
File "src/sage/categories/coalgebras.py", line 262, in sage.categories.coalgebras.Coalgebras.Super.SubcategoryMethods.Supercocommutative
Failed example:
    Coalgebras(ZZ).WithBasis().Super().Supercocommutative()
Expected:
    Category of supercocommutative super coalgebras with basis over Integer Ring
Got:
    Category of super coalgebras with basis over Integer Ring
**********************************************************************
File "src/sage/categories/coalgebras.py", line 264, in sage.categories.coalgebras.Coalgebras.Super.SubcategoryMethods.Supercocommutative
Failed example:
    BialgebrasWithBasis(QQ).Super().Supercocommutative()
Expected:
    Join of Category of super algebras with basis over Rational Field
     and Category of super bialgebras over Rational Field
     and Category of super coalgebras with basis over Rational Field
     and Category of supercocommutative super coalgebras over Rational Field
Got:
    Join of Category of super algebras with basis over Rational Field and Category of super bialgebras over Rational Field and Category of super coalgebras with basis over Rational Field
**********************************************************************
1 item had failures:
   2 of   4 in sage.categories.coalgebras.Coalgebras.Super.SubcategoryMethods.Supercocommutative
    [70 tests, 2 failures, 0.40 s]
----------------------------------------------------------------------
sage -t src/sage/categories/coalgebras.py  # 2 doctests failed
----------------------------------------------------------------------

I like the output from those doctests, so I wouldn't want to just delete the class and modify the doctests.

--- a/src/sage/categories/graded_algebras_with_basis.py
+++ b/src/sage/categories/graded_algebras_with_basis.py
+    class SignedTensorProducts(SignedTensorProductsCategory):
+        """
+        The category of algebras with basis constructed by signed tensor
+        product of algebras with basis.
+        """

The word "super", or at least "graded", should probably fall somewhere here.

Can you add doctests verifying that SuperBialgebras are not a subcat of Bialgebras, supercommutative superalgebras are not commutative algebras, and same for supercoalgebras?

I agree that this would be a good idea.

[tscrim]

comment:91

Replying to @jhpalmieri:

Replying to @darijgr:

I can't answer any of the design questions, so I hope Travis will respond, too.

Thank you for answering. I just forgot to do that yesterday. ^^;;

--- a/src/sage/algebras/clifford_algebra.py
+++ b/src/sage/algebras/clifford_algebra.py
-        cat = HopfAlgebrasWithBasis(R).Super().FiniteDimensional()
+        cat = HopfAlgebrasWithBasis(R).FiniteDimensional().Supercommutative().Supercocommutative()

Are you sure it shouldn't be "HopfSuperAlgebrasWithBasis(R)"?

The "Supercommutative" and "Supercocommutative" axioms imply "Super" Hopf algebra, so is this necessary?

As John said, the implication is already there. So adding Super to the first category is overkill.

--- a/src/sage/algebras/steenrod/steenrod_algebra.py
+++ b/src/sage/algebras/steenrod/steenrod_algebra.py
-        from sage.categories.graded_hopf_algebras_with_basis import GradedHopfAlgebrasWithBasis
+        from sage.categories.super_hopf_algebras_with_basis import SuperHopfAlgebrasWithBasis

I see the existence of a Z-grading (as opposed to just as a Z/2-grading) is getting lost here. Is there a way to preserve it? A GradedSuperHopfAlgebrasWithBasis category perhaps? Or are we not having anything that can make use of the grading to begin with?

Maybe a graded object should have a method or attribute grading_group (or whatever you want to call it). I'm not sure how else you would convey this information, because GradedSuperHopfAlgebras... is redundant: super implies graded, and "graded" should make no assumptions about what the grading group is. You could have GradedConnectedSuperHopfAlgebras... because graded + connected implies a Z-grading (at least to me: it doesn't mean "connected as a Hopf algebra" + "graded as a (super) Hopf algebra").

Super implies graded for modules/algebras/etc. (but not as Hopf algebras). The super stuff is controlled by the is_even_odd method that outputs something in Z2Z. You can have the normal Z grading, and as long as whatever grading is naturally compatible with the super grading, you should not have to do anything more.

(Eventually, gradings will be very useful, as they allow you to do linear algebra when the graded parts are finite-dimensional.)

At least with the Steenrod algebra, there is a method homogeneous_component which takes a degree as input and returns the finite dimensional vector space, with basis, for the component in that degree.

--- a/src/sage/categories/coalgebras.py
+++ b/src/sage/categories/coalgebras.py
+    class Cocommutative(CategoryWithAxiom_over_base_ring):
+        """
+        Category of cocommutative coalgebras.
+        """

Is this class meant to be completely empty as it currently stands?

Yes because we cannot do anything special with them other than mark them at this point. Although we could add a test for cocommutative coalgebras with basis to check that it is cocommutative.

+        class SubcategoryMethods:
+            @cached_method
+            def Supercocommutative(self):
+                r"""
+                Return the full subcategory of the supercocommutative
+                objects of ``self``.

This seems to be in the Coalgebras class. But it only makes sense for supercoalgebras. Are we trying to cause spooky action at a distance here?

I tried deleting this and got a few doctest failures:
[snip]
I like the output from those doctests, so I wouldn't want to just delete the class and modify the doctests.

So should supercommutative only be there for algebras? In both cases, it is just a convenience method to shortcut doing Algebras(QQ).Super().Supercommutative() and similarly for coalgebras. -1 for removing them.

--- a/src/sage/categories/graded_algebras_with_basis.py
+++ b/src/sage/categories/graded_algebras_with_basis.py
+    class SignedTensorProducts(SignedTensorProductsCategory):
+        """
+        The category of algebras with basis constructed by signed tensor
+        product of algebras with basis.
+        """

The word "super", or at least "graded", should probably fall somewhere here.

Yes, I just forgot to change this when I moved it. Feel free to add.

Can you add doctests verifying that SuperBialgebras are not a subcat of Bialgebras, supercommutative superalgebras are not commutative algebras, and same for supercoalgebras?

I agree that this would be a good idea.

This already is there and was added as per your request when we first did the super stuff; see coalgebras.py. For the commutative, we already are explicitly forbidding commutative to be passed; see super_modules.py. So adding more tests of this form is redundant IMO.

[darijgr]

comment:92

The "Supercommutative" and "Supercocommutative" axioms imply "Super" Hopf algebra, so is this necessary?

I don't get it. Supercommutative makes no sense as an axiom on a Hopf algebra. Super is not an axiom for Hopf algebras.

This already is there and was added as per your request when we first did the super stuff; see coalgebras.py.

Where?

[tscrim]

comment:93

Replying to @darijgr:

The "Supercommutative" and "Supercocommutative" axioms imply "Super" Hopf algebra, so is this necessary?

I don't get it. Supercommutative makes no sense as an axiom on a Hopf algebra. Super is not an axiom for Hopf algebras.

As soon as you make something supercommutative, you make it into its super version (which, as you note, is not an axiom (but instead a functorial construction)). It is the same as soon as you create the graded X it also knows that it is a filtered X.

This already is there and was added as per your request when we first did the super stuff; see coalgebras.py.

Where?

Line 240-249 of coalgebras.py.

[darijgr]

comment:94

As soon as you make something supercommutative, you make it into its super version (which, as you note, is not an axiom (but instead a functorial construction)). It is the same as soon as you create the graded X it also knows that it is a filtered X.

Ah, so it's a shorthand. I see.

Line 240-249 of coalgebras.py.

Oh! I was looking for it in the diff. Thanks for reminding me!

[jhpalmieri]

Changed reviewer from Travis Scrimshaw, John Palmieri to Travis Scrimshaw, John Palmieri, Darij Grinberg

[jhpalmieri]

comment:95

Okay, I am ready to give this a positive review. Any objections?

[darijgr]

comment:96

I don't have any. But this patch is almost 100% infrastructural, so I'm not the one to ask. Thanks to all of you for taking care of this!

[tscrim]

comment:97

Thank you both (and again to Nicolas for all his help).

[jhpalmieri]

comment:98

Thank you, Travis, for implementing this in a way that makes everyone happy, too!

[vbraun]

Changed branch from public/categories/signed_tensor_products-25603 to ccccd8a