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

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

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

bacbe13

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

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Commit: bacbe13

[jhpalmieri]

comment:5

Here's an attempt.

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from bacbe13 to bf48b87

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

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

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from bf48b87 to 924a106

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

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

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

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

109f3bc

trac 25603: remove comment about super Hopf algebras

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from 924a106 to 109f3bc

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from 109f3bc to 1ac4be4

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

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:23

Here is a new version which just incorporates the sign into super modules/algebras/whatever (although not implemented for everything, just for the tensor product for super algebras and _test_antipode for super Hopf algebras).

Note also that without this branch, elements of an ExteriorAlgebra do not have an antipode, so the TestSuite for such an algebra skips the antipode testing. With this branch, the antipode is tested (and passes).

[d4d9e38a-6e64-40d7-a7f7-bd828eb9e0db]

comment:24

I am trying this out on #25163. Is it normal to require that some_elements be implemented to return some elements of homogeneous degree? I thought this was not clear in the documentation.

The default implement of some_elements returned [self.an_element()] and you should be able to modify this test so that _test_antipode verifies this identity for inhomogeneous elements.

[jhpalmieri]

comment:25

If you want _test_antipode to work with inhomogeneous elements, it will require rewriting. Since the whole testing apparatus is internal, we can decide whether it's easiest for some_elements to always return homogeneous elements (in the super algebra case), or whether we want _test_antipode to work with arbitrary elements (which means breaking those elements into homogeneous components and testing each component separately, so the same test is happening in any case).

[jhpalmieri]

comment:26

We could do this for _test_antipode:

diff --git a/src/sage/categories/super_hopf_algebras_with_basis.py b/src/sage/categories/super_hopf_algebras_with_basis.py
index 59a4fc2408..af196ad85b 100644
--- a/src/sage/categories/super_hopf_algebras_with_basis.py
+++ b/src/sage/categories/super_hopf_algebras_with_basis.py
@@ -74,13 +74,18 @@ class SuperHopfAlgebrasWithBasis(SuperModulesCategory):
             SI = lambda x: self.sum(c * S(self.monomial(t1)) * self.monomial(t2)
                                 for ((t1, t2), c) in x.coproduct())

-            sign = lambda x, y: (-1)**(x.degree() * y.degree())
-
             for x in tester.some_elements():
-
-                # antipode is an anti-homomorphism
+                x_even = x.even_component()
+                x_odd = x.odd_component()
                 for y in tester.some_elements():
-                    tester.assertTrue(S(x) * S(y) == sign(x, y) * S(y * x))
+                    y_even = y.even_component()
+                    y_odd = y.odd_component()
+
+                    # The antipode is a graded anti-homomorphism.
+                    tester.assertTrue(S(x_even) * S(y_even) == S(y_even * x_even))
+                    tester.assertTrue(S(x_even) * S(y_odd) == S(y_odd * x_even))
+                    tester.assertTrue(S(x_odd) * S(y_even) == S(y_even * x_odd))
+                    tester.assertTrue(S(x_odd) * S(y_odd) == -S(y_odd * x_odd))

                 # mu * (S # I) * delta == counit * unit
                 tester.assertTrue(SI(x) == self.counit(x) * self.one())

Would that be better?

[d4d9e38a-6e64-40d7-a7f7-bd828eb9e0db]

comment:27

Replying to @jhpalmieri:

Would that be better?

+1. This avoids having to know to implement a some_elements method which returns some homogeneous elements in order for _test_antipode to work.

[darijgr]

comment:28

+    class TensorProducts(TensorProductsCategory):
+        """
+        The category of algebras with basis constructed by tensor product of super algebras with basis

You mean "The category of super...", right?

+        """
+
+        class ParentMethods:
+            """
+            implements operations on tensor products of algebras with basis
+            """

Again, super I assume.

I don't get the product_on_basis code. What is self._sets? Why is the parity a sum of things?

I'm not happy with this:

+    def extra_super_categories(self):
+        return [self.base_category().Graded()]

Didn't we already agree that a super Hopf algebra is not a graded Hopf algebra?

[jhpalmieri]

comment:29

Replying to @darijgr:

+    class TensorProducts(TensorProductsCategory):
+        """
+        The category of algebras with basis constructed by tensor product of super algebras with basis

You mean "The category of super...", right?

Right.

+        """
+
+        class ParentMethods:
+            """
+            implements operations on tensor products of algebras with basis
+            """

Again, super I assume.

Right.

I don't get the product_on_basis code. What is self._sets? Why is the parity a sum of things?

self._sets is the list of the tensor factors of self – a list of super algebras. When you compute the product

(a_0 tensor a_1 tensor ... tensor a_{n-1}) (b_0 tensor b_1 tensor ... tensor b_{n-1})

you have to commute b_1 past a_i for i between 1 and n-1, and each such interchange multiplies by (-1) raised to the appropriate power. Multiplying the powers of (-1) for all of these interchanges corresponds to first adding all of the powers and then raising (-1) to that power.

I'm not happy with this:

+    def extra_super_categories(self):
+        return [self.base_category().Graded()]

Didn't we already agree that a super Hopf algebra is not a graded Hopf algebra?

This is what turns on the antipode method for elements of exterior algebras, for example. I'd like to treat super Hopf algebras as graded Hopf algebras, except we can override the necessary methods in, for example, super_hopf_algebras_with_basis.py.

What would you suggest instead?

[darijgr]

comment:30

Oh!! I forgot that a tensor can have several factors... I still don't get the code though. Why self._sets[0] and self._sets[1], not just self._sets?

I don't like the "we can override the necessary methods" reasoning -- sure we can do it now, but will everyone who later implements a new Hopf-algebra method do the same? Will they even know that they're supposed to do that?

[jhpalmieri]

comment:31

Replying to @darijgr:

Oh!! I forgot that a tensor can have several factors... I still don't get the code though. Why self._sets[0] and self._sets[1], not just self._sets?

Because I forgot that a tensor can have several factors? I think I was confusing self._sets[0] with the parent of the left factor in the product. I'll fix that.

I don't like the "we can override the necessary methods" reasoning -- sure we can do it now, but will everyone who later implements a new Hopf-algebra method do the same? Will they even know that they're supposed to do that?

If they implement a test for it, which then fails on exterior algebras or odd primary Steenrod algebras, they'll know.

As I asked before, what do you suggest instead? The whole category framework is frustrating, in how badly it's documented. I don't even know where to start if we are going to take a different approach.

[darijgr]

comment:32

I don't know what I'd do, and I have largely the same issue with the category framework. I'd copypaste whatever category (ConnectedGradedHopfAlgebras I guess?) is responsible for auto-computing the antipode, and copypaste it into a super version (ConnectedGradedSuperHopfAlgebras?).

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from 1ac4be4 to efcb5ab

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

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

0d960f6	trac 25603: allow _test_antipode to work on nonhomogeneous elements.
efcb5ab	trac 25603: fix bug in product in tensor products of super algebras

[jhpalmieri]

comment:34

On a branch on my computer, I wrote versions of super_coalgebras.py, super_bialgebras.py, super_hopf_algebras.py, and I get behavior that I just can't understand. In super_hopf_algebras.py`, for example (omitting docstrings for brevity):

class SuperHopfAlgebras(SuperModulesCategory):

    def super_categories(self):
        R = self.base_ring()
        return [SuperBialgebras(R)]

    def dual(self):
        return self

(This was essentially copied from hopf_algebra.py.) Then within Sage:

sage: from sage.categories.super_hopf_algebras import SuperHopfAlgebras
sage: H = SuperHopfAlgebras(QQ)
sage: H
Category of super hopf algebras over Rational Field
sage: H.dual()
Join of Category of duals of coalgebras over Rational Field and Category of duals of algebras over Rational Field

or more succinctly:

sage: H.dual() == H # should return True
False

If I evaluate H.dual??, it does not give me return self as the source code. Where is it inheriting from? And why? Is the dual method in the old hopf_algebra.py just a red herring?

If someone else wants to take this over, or wants to explain it to me clearly and in short sentences, great. Otherwise, I may be forced to leave this as is and hope it's good enough.

[fchapoton]

Author: John Palmieri

[tscrim]

comment:36

You have put dual in the category, not the ParentMethods. So that is why it is not working.

[tscrim]

comment:37

I am also a little uncomfortable with super Hopf => graded Hopf at the category level to get the methods. I think the better thing to do is make aliases for things from GradedHopfAlgebras[WithBasis] for the methods that make sense (you may need to apply __func__ afterwards; I think there is a better way for Python3 compatibility, but I forget what it is off the top of my head). The other option is, of course, a straight copy/paste.

I am liking this implementation better. In my (very limited) experience, the super algebras should have the sign graded tensor products by default. If we happen to get some super algebras whose tensor products should not have the sign (or complaints), we can revisit this issue then.

Also, typically we don't have docstrings for the ParentMethods (and similar) class.

[jhpalmieri]

comment:38

I feel like I'm just trying things at random here, cutting and pasting from various files in the categories directory, and it's not enjoyable. Why does HopfAlgebras in hopf_algebras.py have a super_categories method, as compared to SuperAlgebras which has an extra_super_categories method? Which should I use for SuperHopfAlgebras? Which for SuperHopfAlgebrasWithBasis?

Moving def dual to the ParentMethods section makes no difference, not that I understand why it would. Note also that in hopf_algebra.py, def dual is not in ParentMethods. So I'm still confused about this.

I created a file super_coalgebras.py, modeling it on super_algebras.py:

class SuperCoalgebras(SuperModulesCategory):

    def extra_super_categories(self):
        return [self.base_category().Graded()]

I also modified coalgebras.py by removing the class Super(...). But this didn't work: I got

**********************************************************************
File "src/sage/categories/super_coalgebras.py", line 44, in sage.categories.super_coalgebras.SuperCoalgebras.extra_super_categories
Failed example:
    C.super_categories() # indirect doctest
Expected:
    [Category of super modules over Integer Ring,
     Category of graded coalgebras over Integer Ring]
Got:
    [Category of super modules over Integer Ring,
     Category of coalgebras over Integer Ring]
**********************************************************************

And of course, if anyone manages to answer these questions, I fully expect to get stuck 5 minutes later on something else. I just don't understand enough of the category framework to do this in anything approaching an efficient way. So I really think someone else should take over, if you're not happy with the current approach. Or accept this approach for now and open a followup ticket to use a better approach – I would appreciate this if otherwise this ticket might get delayed for a significant amount of time.

[tscrim]

comment:39

Replying to @jhpalmieri:

I feel like I'm just trying things at random here, cutting and pasting from various files in the categories directory, and it's not enjoyable. Why does HopfAlgebras in hopf_algebras.py have a super_categories method, as compared to SuperAlgebras which has an extra_super_categories method? Which should I use for SuperHopfAlgebras? Which for SuperHopfAlgebrasWithBasis?

HopfAlgebras is not a functorially constructed category, as opposed to the Super* categories. So that is why it needs the super_categories.

Moving def dual to the ParentMethods section makes no difference, not that I understand why it would. Note also that in hopf_algebra.py, def dual is not in ParentMethods. So I'm still confused about this.

Well, the dual there is the for the dual category, which is some category theoretical thing that I don't know about. Anything defined in ParentMethods becomes a method for any Parent object in that category (e.g., an exterior algebra). I misread your previous post; so yes, I agree that what you have above should be True.

I created a file super_coalgebras.py, modeling it on super_algebras.py:

class SuperCoalgebras(SuperModulesCategory):

    def extra_super_categories(self):
        return [self.base_category().Graded()]

I also modified coalgebras.py by removing the class Super(...). But this didn't work: I got

**********************************************************************
File "src/sage/categories/super_coalgebras.py", line 44, in sage.categories.super_coalgebras.SuperCoalgebras.extra_super_categories
Failed example:
    C.super_categories() # indirect doctest
Expected:
    [Category of super modules over Integer Ring,
     Category of graded coalgebras over Integer Ring]
Got:
    [Category of super modules over Integer Ring,
     Category of coalgebras over Integer Ring]
**********************************************************************

Did you add a redirect from coalgebras to the super version? Coalgebras still needs to know what class its super version is. (See, e.g., ModulesWithBasis.)

And of course, if anyone manages to answer these questions, I fully expect to get stuck 5 minutes later on something else. I just don't understand enough of the category framework to do this in anything approaching an efficient way. So I really think someone else should take over, if you're not happy with the current approach. Or accept this approach for now and open a followup ticket to use a better approach – I would appreciate this if otherwise this ticket might get delayed for a significant amount of time.

I will take over then and try to get this to a workable state.

[jhpalmieri]

comment:40

Replying to @tscrim:

Well, the dual there is the for the dual category, which is some category theoretical thing that I don't know about. Anything defined in ParentMethods becomes a method for any Parent object in that category (e.g., an exterior algebra). I misread your previous post; so yes, I agree that what you have above should be True.

I don't dual categories are that useful in Sage, nor do I care about them in this particular case, so probably the easiest thing to do is to delete this part.

I created a file super_coalgebras.py, modeling it on super_algebras.py:

[snip]

Did you add a redirect from coalgebras to the super version? Coalgebras still needs to know what class its super version is. (See, e.g., ModulesWithBasis.)

I put in a Super = LazyImport(...) line, like the one in algebras.py.

And of course, if anyone manages to answer these questions, I fully expect to get stuck 5 minutes later on something else. I just don't understand enough of the category framework to do this in anything approaching an efficient way. So I really think someone else should take over, if you're not happy with the current approach. Or accept this approach for now and open a followup ticket to use a better approach – I would appreciate this if otherwise this ticket might get delayed for a significant amount of time.

I will take over then and try to get this to a workable state.

That would be great, thanks.

[tscrim]

comment:41

Nicolas and I discussed this a bit at SageDays@ICERM. What we concluded was that there should be a new functorial construction SignedTensorProducts. We should also add a new axiom super-commutative. Then for SuperCommutativeAlgebras, we should override the tensor constructor so the default was the signed version. Anytime we have methods that would be shared with two otherwise separate categories (e.g., (super) Hopf algebras), we create just an ABC, where now the "C" is for "Category"; see ComplexReflectionOrGeneralizedCoxeterGroups as an example.

If you do not disagree with this, I will take this over now and do all of these things.

[darijgr]

comment:42

Replying to @tscrim:

Nicolas and I discussed this a bit at SageDays@ICERM. What we concluded was that there should be a new functorial construction SignedTensorProducts. We should also add a new axiom super-commutative. Then for SuperCommutativeAlgebras, we should override the tensor constructor so the default was the signed version.

OK, as long as these SuperCommutativeAlgebras inherit from SuperAlgebras and not from Algebras.

Anytime we have methods that would be shared with two otherwise separate categories (e.g., (super) Hopf algebras), we create just an ABC, where now the "C" is for "Category"; see ComplexReflectionOrGeneralizedCoxeterGroups as an example.

This sounds like the Right Thing To Do. Definitely agreeing.

[d4d9e38a-6e64-40d7-a7f7-bd828eb9e0db]

comment:43

This sounds great. I'm glad you are taking this up because I'd like it for #25163.

Can you clarify what the super-commutative axiom will mean (I can also be patient and see what you have in mind)? Are you saying that an algebra is super-commutative if fg = (-1)^x gf for elements f and g?

[jhpalmieri]

comment:44

This mostly sounds good to me, but some algebras which are not commutative or supercommutative (like the Steenrod algebra, or perhaps enveloping algebras for super Lie algebras) should still have the sign in the tensor product. So as long as the new functorial construction is well documented and easy to apply in these non-supercommutative cases, okay.

Perhaps also implement SuperCocommutativeCoalgebras? It would be nice to say that the Steenrod algebra is super cocommutative, and that therefore it gets the sign on the tensor product, even though the product is not commutative.

[tscrim]

comment:45

Replying to @zabrocki:

This sounds great. I'm glad you are taking this up because I'd like it for #25163.

Can you clarify what the super-commutative axiom will mean (I can also be patient and see what you have in mind)? Are you saying that an algebra is super-commutative if fg = (-1)^x gf for elements f and g?

Yes, that is correct. Is there some other notion of super-commutative that I/we should be worried about?

[tscrim]

comment:46

Replying to @jhpalmieri:

This mostly sounds good to me, but some algebras which are not commutative or supercommutative (like the Steenrod algebra, or perhaps enveloping algebras for super Lie algebras) should still have the sign in the tensor product. So as long as the new functorial construction is well documented and easy to apply in these non-supercommutative cases, okay.

That is the plan. It might take a few iterations (on trac) to get something that works in all the case you want, so please bear with me.

Perhaps also implement SuperCocommutativeCoalgebras? It would be nice to say that the Steenrod algebra is super cocommutative, and that therefore it gets the sign on the tensor product, even though the product is not commutative.

That should be no trouble to do as well. Actually, we currently do not even have a cocommutative axiom. It might be better to introduce these on a separate ticket.