Opened 3 years ago

Closed 2 years ago

# Signed tensor product for graded algebras, coalgebras, etc.

Reported by: Owned by: jhpalmieri major sage-8.9 categories fpsac2019 tscrim, nthiery, cnassau John Palmieri, Travis Scrimshaw Travis Scrimshaw, John Palmieri, Darij Grinberg N/A ccccd8a ccccd8a8aa593d7042497103e1b3e90bd259296e

### Description

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.

### comment:1 Changed 3 years ago by jhpalmieri

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

### comment:4 Changed 3 years ago by git

• Commit set to bacbe13d20f73b65f728741fcd03cdfed7c15aa7

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

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

### comment:5 Changed 3 years ago by jhpalmieri

Here's an attempt.

### comment:6 Changed 3 years ago by git

• Commit changed from bacbe13d20f73b65f728741fcd03cdfed7c15aa7 to bf48b877e1eb805197f78d892b95f15b04a0cf89

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

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

### comment:7 Changed 3 years ago by jhpalmieri

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.

### comment:8 Changed 3 years ago by tscrim

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.

### comment:9 Changed 3 years ago by jhpalmieri

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

### comment:10 Changed 3 years ago by jhpalmieri

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.

### comment:11 Changed 3 years ago by tscrim

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)

### comment:12 follow-up: ↓ 13 Changed 3 years ago by gh-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.

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.

Last edited 3 years ago by gh-darijgr (previous) (diff)

### comment:13 in reply to: ↑ 12 Changed 3 years ago by jhpalmieri

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.

### comment:14 follow-up: ↓ 15 Changed 3 years ago by gh-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.

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.

### comment:15 in reply to: ↑ 14 Changed 3 years ago by jhpalmieri

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

### comment:16 Changed 3 years ago by jhpalmieri

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?

### comment:17 Changed 3 years ago by jhpalmieri

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


### comment:18 Changed 3 years ago by git

• Commit changed from bf48b877e1eb805197f78d892b95f15b04a0cf89 to 924a10612a568328a8b45775358150fdc3b178f7

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

### comment:19 Changed 3 years ago by git

• Commit changed from 924a10612a568328a8b45775358150fdc3b178f7 to 109f3bc703ef0863c6706945e156aa9b03db0b4b

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

 ​109f3bc trac 25603: remove comment about super Hopf algebras

### comment:20 Changed 3 years ago by jhpalmieri

• Status changed from new to needs_review

### comment:21 Changed 3 years ago by git

• Commit changed from 109f3bc703ef0863c6706945e156aa9b03db0b4b to 1ac4be42cf527b2fe7368ad588959d34b0fb1a7d

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

 ​1ac4be4 trac 25603: make sure the TestSuite for some exterior algebras

### comment:22 Changed 3 years ago by gh-darijgr

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.

### comment:23 Changed 3 years ago by jhpalmieri

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

### comment:24 Changed 3 years ago by zabrocki

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.

### comment:25 Changed 3 years ago by jhpalmieri

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

### comment:26 follow-up: ↓ 27 Changed 3 years ago by jhpalmieri

We could do this for _test_antipode:

• ## src/sage/categories/super_hopf_algebras_with_basis.py

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

### comment:27 in reply to: ↑ 26 Changed 3 years ago by zabrocki

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.

### comment:28 follow-up: ↓ 29 Changed 3 years ago by gh-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?

+        """
+
+        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):


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

Last edited 3 years ago by gh-darijgr (previous) (diff)

### comment:29 in reply to: ↑ 28 Changed 3 years ago by jhpalmieri

+    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):


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.

### comment:30 follow-up: ↓ 31 Changed 3 years ago by gh-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?

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?

### comment:31 in reply to: ↑ 30 Changed 3 years ago by jhpalmieri

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.

### comment:32 Changed 3 years ago by gh-darijgr

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

### comment:33 Changed 3 years ago by git

• Commit changed from 1ac4be42cf527b2fe7368ad588959d34b0fb1a7d to efcb5abbfa75435a4fd63840220de8c33effd8a1

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

### comment:34 Changed 3 years ago by jhpalmieri

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.

### comment:35 Changed 3 years ago by chapoton

• Authors set to John Palmieri

### comment:36 Changed 3 years ago by tscrim

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

### comment:37 Changed 3 years ago by tscrim

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.

### comment:38 follow-up: ↓ 39 Changed 3 years ago by 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?

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


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.

### comment:39 in reply to: ↑ 38 ; follow-up: ↓ 40 Changed 3 years ago by tscrim

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


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.

### comment:40 in reply to: ↑ 39 Changed 3 years ago by jhpalmieri

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.

### comment:41 follow-up: ↓ 42 Changed 3 years ago by 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. 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.

### comment:42 in reply to: ↑ 41 Changed 3 years ago by gh-darijgr

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.

### comment:43 follow-up: ↓ 45 Changed 3 years ago by 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?

### comment:44 follow-up: ↓ 46 Changed 3 years ago by 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.

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.

### comment:45 in reply to: ↑ 43 Changed 3 years ago by tscrim

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?

### comment:46 in reply to: ↑ 44 ; follow-up: ↓ 47 Changed 3 years ago by tscrim

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.

### comment:47 in reply to: ↑ 46 Changed 3 years ago by 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.

Okay, sounds good.

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.

Sure, a separate ticket would be good.

### comment:48 Changed 2 years ago by chapoton

• Milestone changed from sage-8.3 to sage-8.8
• Status changed from needs_review to needs_work

red branch

### comment:49 Changed 2 years ago by git

• Commit changed from efcb5abbfa75435a4fd63840220de8c33effd8a1 to 67a937c53c073ecdb947a9569061901cf1cede8f

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

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

### comment:50 Changed 2 years ago by jhpalmieri

• Status changed from needs_work to needs_review

Rebased.

Meanwhile, ping! It's been 10 months. I understand that you are not delighted with my approach, but I think it is (much) better than nothing. If there is no progress on this soon, please consider merging this and then fixing it later.

### comment:51 Changed 2 years ago by chapoton

• Branch changed from u/jhpalmieri/graded-tensor to public/ticket/25603
• Commit changed from 67a937c53c073ecdb947a9569061901cf1cede8f to 90b468a585868dea09f52b5928301608274300d2

The branch was still very red. Here is a better merge.

New commits:

 ​90b468a Merge with 8.8.rc1

### comment:52 Changed 2 years ago by git

• Commit changed from 90b468a585868dea09f52b5928301608274300d2 to b0f5fb0102599ce3d69b0e384aff7fd233c26795

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

 ​b0f5fb0 trac 25603 fix some pyflakes details

### comment:53 Changed 2 years ago by chapoton

still missing one doctest, as the coverage report says:

+categories/super_hopf_algebras_with_basis.py: 50.0% (1 of 2)


### comment:54 Changed 2 years ago by git

• Commit changed from b0f5fb0102599ce3d69b0e384aff7fd233c26795 to b77c592c59aefe18478d18b371fb9f7ece2ca19a

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

 ​b77c592 trac 25603: one more doctest

### comment:55 Changed 2 years ago by jhpalmieri

Here is a doctest.

### comment:56 Changed 2 years ago by chapoton

Bot is now fully green, thanks. Travis, any opinion on what to do here ?

### comment:57 Changed 2 years ago by tscrim

Sorry, I kept meaning to get to this and kept getting distracted and putting it off. I don't like putting in place a solution that is not really good as it can take a fair bit of work to get to a better state. I need to implement what Nicolas and I discussed as stated in comment:41. Can you give me another ~3 weeks to do the work at the FPSAC SageDays? (Frédéric, Mike, and Darij will you be there? Perhaps we can do some work there too.) I am doing workshop after conference until then, so I cannot do it before then unfortunately.

### comment:58 follow-up: ↓ 62 Changed 2 years ago by gh-darijgr

I'll be at Sagedays, but I am not very up to date on this. I definitely do not like that a super-Hopf algebra has "graded Hopf algebras" as supercategory; while Hopf defined them in that way, this goes against 90% of usage in algebraic combinatorics. (Also, does the degree method mean to return the parity or the ZZ-degree if both exist?) But as you have probably noticed, I am being overly conservative with inheritance since I have no mental model of the consequences of category hierarchies; apparently parts of sage stretch the category system quite successfully. Frankly I just don't want to be the reviewer who gets flamed for regressions...

### comment:59 Changed 2 years ago by zabrocki

I'd say "Don't let perfect be the enemy of the good". I'm happy with a solution that works. I won't be at Sage Days but we can talk about it at FPSAC if you will be there. I can take a look next week (I've got 2 more days of Garsiafest).

### comment:60 follow-up: ↓ 61 Changed 2 years ago by tscrim

There can be a difference between something good and something that works. I agree this is the latter group, but I do not really think it is in the former. It can also get us into a place where detangling the two ideas becomes more work than the initial effort.

John, I know I owe you a big apology for letting this fall off my radar and not being able to do what I promise sooner.

Addendum: Mike, enjoy Garciafest. I wish I could have gone. I am now on my way to UC Davis for the workshop there.

Last edited 2 years ago by tscrim (previous) (diff)

### comment:61 in reply to: ↑ 60 ; follow-up: ↓ 64 Changed 2 years ago by jhpalmieri

There can be a difference between something good and something that works. I agree this is the latter group, but I do not really think it is in the former. It can also get us into a place where detangling the two ideas becomes more work than the initial effort.

There is a cost-benefit analysis to be done. How much will we gain by putting in something that works? How much longer will it take to put in something "good"? What do we lose in the intervening time? This all depends on how much better the second version is, and how long it takes to implement.

I ask that if there is no better solution available by the end of the summer, you seriously consider accepting my approach.

John, I know I owe you a big apology for letting this fall off my radar and not being able to do what I promise sooner.

I appreciate that. Of course it is not just you; as several of us have discussed on this ticket, the documentation for the category stuff is not in great shape, or else I could have done some or all of this myself.

### comment:62 in reply to: ↑ 58 Changed 2 years ago by jhpalmieri

I definitely do not like that a super-Hopf algebra has "graded Hopf algebras" as supercategory; while Hopf defined them in that way, this goes against 90% of usage in algebraic combinatorics.

Whatever we do, we need to document it very well, because I think that different people use "graded Hopf algebra" (for example) to mean different things. In algebraic topology, it includes the sign in the tensor product, and I am deducing that this is not the case in combinatorics, right?

I would also point out that so far in Sage, "super" just means Z/2-graded (from what I see in a few docstrings), and therefore any "super blah" should also be a "blah" and a "graded blah". So maybe "super Hopf algebra" is not the right name in Sage for the objects which have this sign on the tensor product. Either that or we need to clarify the documentation for what "super" means in Sage, or at least what "super Hopf algebra" means, pointing out that in Sage, if this is indeed the choice we make, a "super Hopf algebra" need not be a Hopf algebra while a "graded Hopf algebra" is one.

Actually, given the conflict in what "graded Hopf algebra" means to different mathematicians, my inclination would be to avoid the phrase altogether, and instead have something like "Hopf algebra with grading" for the combinatorial version, and I'm not sure what for the algebraic topology version.

### comment:63 Changed 2 years ago by gh-darijgr

Whatever we do, we need to document it very well, because I think that different people use "graded Hopf algebra" (for example) to mean different things. In algebraic topology, it includes the sign in the tensor product, and I am deducing that this is not the case in combinatorics, right?

Correct. The idea, I think, is that our graded Hopf algebras are understood as graded algebras with extra features. And few commutative algebraists or algebraic geometers would artificially duplicate the degrees of all polynomials just so that they can say that the polynomial ring is commutative (the exception is Eisenbud in an appendix to his book, but not in the rest of the book). To my knowledge, the only algebraic combinatorialists who include signs in their graded Hopf algebras by default are some invariant theorists around Rota.

Thinking of it this way, it's a nice example of a diamond inheritance failure in mathematics :)

I would also point out that so far in Sage, "super" just means Z/2-graded (from what I see in a few docstrings), and therefore any "super blah" should also be a "blah" and a "graded blah". So maybe "super Hopf algebra" is not the right name in Sage for the objects which have this sign on the tensor product. Either that or we need to clarify the documentation for what "super" means in Sage, or at least what "super Hopf algebra" means, pointing out that in Sage, if this is indeed the choice we make, a "super Hopf algebra" need not be a Hopf algebra while a "graded Hopf algebra" is one.

The problem is: you can say that a superalgebra is an algebra with extra structure, but a tensor product of superalgebras is not a tensor product of the underlying algebras with extra structure. And I don't know if this kind of nuance can survive the Sage category framework.

Actually, given the conflict in what "graded Hopf algebra" means to different mathematicians, my inclination would be to avoid the phrase altogether, and instead have something like "Hopf algebra with grading" for the combinatorial version, and I'm not sure what for the algebraic topology version.

Super-Hopf algebra with grading, I'd say. I would otherwise call it graded super-Hopf algebra or graded Hopf superalgebra.

### comment:64 in reply to: ↑ 61 Changed 2 years ago by tscrim

There can be a difference between something good and something that works. I agree this is the latter group, but I do not really think it is in the former. It can also get us into a place where detangling the two ideas becomes more work than the initial effort.

There is a cost-benefit analysis to be done. How much will we gain by putting in something that works? How much longer will it take to put in something "good"? What do we lose in the intervening time? This all depends on how much better the second version is, and how long it takes to implement.

I ask that if there is no better solution available by the end of the summer, you seriously consider accepting my approach.

If I do not have it (nearly) done by the end of SageDays?, I will set the positive review myself.

### comment:65 Changed 2 years ago by jhpalmieri

I am hopeful that you will make progress, so I don't plan to work on my version. If it gets to the point that we have to settle for mine, I should probably clean up some things: add some documentation (as discussed with Darij above), and I guess remove graded Hopf algebras as a supercategory for super Hopf algebras. I'll wait to do any of this, in the hope that I won't ever have to.

Last edited 2 years ago by jhpalmieri (previous) (diff)

### comment:66 Changed 2 years ago by embray

• Milestone changed from sage-8.8 to sage-8.9

Moving tickets from the Sage 8.8 milestone that have been actively worked on in the last six months to the next release milestone (optimistically).

### comment:67 Changed 2 years ago by tscrim

• Authors changed from John Palmieri to John Palmieri, Travis Scrimshaw
• Branch changed from public/ticket/25603 to public/categories/signed_tensor_products-25603
• Commit changed from b77c592c59aefe18478d18b371fb9f7ece2ca19a to 3ffd801a50d4ef882a97bee4359e33053b584b0c

Okay, here is the proposal I have worked on with a fair bit of input from Nicolas (thank you!) that was sketched out in comment:41. So functionally it works by anything with a super defaults to using the signed tensor product where this makes sense. I did this by a little trick of setting the _functor_name to also use the same constructor, which is then overwritten by the SuperAlgebras category. I also added the axioms (super)cocommutative for people to build upon and mark classes as necessary. I put the exterior algebra in the category of supercommutative algebras. Ready for review.

Addendum - John, I left you on as an author since I was using a number of your changes from your branch.

New commits:

 ​e7a692c Adding cocommutative axiom. ​fa35408 Implementation of signed_tensor construction. ​3ffd801 Adding supercocommutative axiom.
Last edited 2 years ago by tscrim (previous) (diff)

### comment:68 Changed 2 years ago by jhpalmieri

Thanks very much for working on this! I see one doctest failure with Python 2 (easy to fix):

File "src/sage/categories/with_realizations.py", line 262, in sage.categories.with_realizations.WithRealizations
Failed example:
C.super_categories()
Expected:
[Join of Category of hopf algebras over Rational Field
and Category of graded algebras over Rational Field]
Got:
[Join of Category of hopf algebras over Rational Field and Category of graded algebras over Rational Field and Category of graded coalgebras over Rational Field]


I see a few more with Python 3:

File "src/sage/categories/supercommutative_algebras.py", line 77, in sage.categories.supercommutative_algebras.SupercommutativeAlgebras.WithBasis.ParentMethods._test_supercommutativity
Failed example:
E._test_supercommutativity()
Expected nothing
Got:
doctest:warning
File "/Users/palmieri/Desktop/Sage_stuff/sage_builds/PYTHON3/sage-8.9.beta2/src/bin/sage-runtests", line 179, in <module>
err = DC.run()
File "/Users/palmieri/Desktop/Sage_stuff/sage_builds/PYTHON3/sage-8.9.beta2/local/lib/python3.7/site-packages/sage/doctest/control.py", line 1232, in run
self.run_doctests()
File "/Users/palmieri/Desktop/Sage_stuff/sage_builds/PYTHON3/sage-8.9.beta2/local/lib/python3.7/site-packages/sage/doctest/control.py", line 933, in run_doctests
self.dispatcher.dispatch()
File "/Users/palmieri/Desktop/Sage_stuff/sage_builds/PYTHON3/sage-8.9.beta2/local/lib/python3.7/site-packages/sage/doctest/forker.py", line 2010, in dispatch
self.parallel_dispatch()
File "/Users/palmieri/Desktop/Sage_stuff/sage_builds/PYTHON3/sage-8.9.beta2/local/lib/python3.7/site-packages/sage/doctest/forker.py", line 1907, in parallel_dispatch
w.start()  # This might take some time
File "/Users/palmieri/Desktop/Sage_stuff/sage_builds/PYTHON3/sage-8.9.beta2/local/lib/python3.7/site-packages/sage/doctest/forker.py", line 2193, in start
super(DocTestWorker, self).start()
File "/Users/palmieri/Desktop/Sage_stuff/sage_builds/PYTHON3/sage-8.9.beta2/local/lib/python3.7/multiprocessing/process.py", line 112, in start
self._popen = self._Popen(self)
File "/Users/palmieri/Desktop/Sage_stuff/sage_builds/PYTHON3/sage-8.9.beta2/local/lib/python3.7/multiprocessing/context.py", line 223, in _Popen
return _default_context.get_context().Process._Popen(process_obj)
File "/Users/palmieri/Desktop/Sage_stuff/sage_builds/PYTHON3/sage-8.9.beta2/local/lib/python3.7/multiprocessing/context.py", line 277, in _Popen
return Popen(process_obj)
File "/Users/palmieri/Desktop/Sage_stuff/sage_builds/PYTHON3/sage-8.9.beta2/local/lib/python3.7/multiprocessing/popen_fork.py", line 20, in __init__
self._launch(process_obj)
File "/Users/palmieri/Desktop/Sage_stuff/sage_builds/PYTHON3/sage-8.9.beta2/local/lib/python3.7/multiprocessing/popen_fork.py", line 74, in _launch
code = process_obj._bootstrap()
File "/Users/palmieri/Desktop/Sage_stuff/sage_builds/PYTHON3/sage-8.9.beta2/local/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/Users/palmieri/Desktop/Sage_stuff/sage_builds/PYTHON3/sage-8.9.beta2/local/lib/python3.7/site-packages/sage/doctest/forker.py", line 2149, in run
File "/Users/palmieri/Desktop/Sage_stuff/sage_builds/PYTHON3/sage-8.9.beta2/local/lib/python3.7/site-packages/sage/doctest/forker.py", line 2487, in __call__
doctests, extras = self._run(runner, options, results)
File "/Users/palmieri/Desktop/Sage_stuff/sage_builds/PYTHON3/sage-8.9.beta2/local/lib/python3.7/site-packages/sage/doctest/forker.py", line 2536, in _run
result = runner.run(test)
File "/Users/palmieri/Desktop/Sage_stuff/sage_builds/PYTHON3/sage-8.9.beta2/local/lib/python3.7/site-packages/sage/doctest/forker.py", line 879, in run
return self._run(test, compileflags, out)
File "/Users/palmieri/Desktop/Sage_stuff/sage_builds/PYTHON3/sage-8.9.beta2/local/lib/python3.7/site-packages/sage/doctest/forker.py", line 681, in _run
self.compile_and_execute(example, compiler, test.globs)
File "/Users/palmieri/Desktop/Sage_stuff/sage_builds/PYTHON3/sage-8.9.beta2/local/lib/python3.7/site-packages/sage/doctest/forker.py", line 1105, in compile_and_execute
exec(compiled, globs)
File "<doctest sage.categories.supercommutative_algebras.SupercommutativeAlgebras.WithBasis.ParentMethods._test_supercommutativity[1]>", line 1, in <module>
E._test_supercommutativity()
File "/Users/palmieri/Desktop/Sage_stuff/sage_builds/PYTHON3/sage-8.9.beta2/local/lib/python3.7/site-packages/sage/categories/supercommutative_algebras.py", line 97, in _test_supercommutativity
* (y * x))
File "/Users/palmieri/Desktop/Sage_stuff/sage_builds/PYTHON3/sage-8.9.beta2/local/lib/python3.7/unittest/case.py", line 1337, in deprecated_func
DeprecationWarning, 2)
File "/Users/palmieri/Desktop/Sage_stuff/sage_builds/PYTHON3/sage-8.9.beta2/local/lib/python3.7/warnings.py", line 110, in _showwarnmsg
msg.file, msg.line)
:
**********************************************************************
1 of   5 in sage.categories.supercommutative_algebras.SupercommutativeAlgebras.WithBasis.ParentMethods._test_supercommutativity


and failures from the same deprecation warning in algebras/clifford_algebra.py.

(I haven't actually run the full test suite, just tests in algebras and categories.)

I'll be working my way through the code.

### comment:69 Changed 2 years ago by jhpalmieri

The "docstring" for signed_tensor is not working the way you want. I suggest this change:

• ## src/sage/categories/signed_tensor.py

diff --git a/src/sage/categories/signed_tensor.py b/src/sage/categories/signed_tensor.py
index 493df0ea90..6d2873c04b 100644
 a class SignedTensorProductFunctor(CovariantFunctorialConstruction): of Algebras(QQ).Graded(). This nested class is itself a subclass of :class:~sage.categories.signed_tensor.SignedTensorProductsCategory. EXAMPLES:: sage: signed_tensor The signed tensor functorial construction TESTS:: sage: TestSuite(signed_tensor).run() class SignedTensorProductFunctor(CovariantFunctorialConstruction): return "The signed tensor functorial construction" signed_tensor = SignedTensorProductFunctor() """ The signed tensor product functorial construction. See :class:~sage.categories.signed_tensor.SignedTensorProductFunctor for more information. EXAMPLES:: sage: signed_tensor The signed tensor functorial construction """ class SignedTensorProductsCategory(CovariantConstructionCategory): r"""

Do you want to include signed_tensor.py and also supercommutative_algebras.py in the reference manual?

### comment:70 Changed 2 years ago by jhpalmieri

Should signed_tensor be a top-level command? I don't know if that's necessary. If so, should it instead be tensor_signed so it can be discovered maybe more naturally using tab-completion?

### comment:71 Changed 2 years ago by git

• Commit changed from 3ffd801a50d4ef882a97bee4359e33053b584b0c to 1b0496eef52fb0317c2aa3d4ebc756d6ace55bd9

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

 ​1b0496e trac 25603: a few doctest and other minor fixes.

### comment:72 Changed 2 years ago by jhpalmieri

This fixes the doctest failures and makes a few other changes. No changes to signed_tensor, since I don't know what you think about my comments and questions.

### comment:73 Changed 2 years ago by jhpalmieri

Overall it looks good. Maybe on a followup ticket we can add some documentation clarifying that graded Hopf algebras are actually Hopf algebras, whereas super Hopf algebras are not (i.e., making sure that algebraic topologists know what they're getting into).

### comment:74 Changed 2 years ago by git

• Commit changed from 1b0496eef52fb0317c2aa3d4ebc756d6ace55bd9 to 1f1f5537d0962571c1adcda05147457ccac58615

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

 ​1f1f553 trac 25603: more doctest fixes

### comment:75 Changed 2 years ago by jhpalmieri

Here are more easy doctest fixes. There is one failure I don't know what to do with:

**********************************************************************
File "src/sage/misc/c3_controlled.pyx", line 331, in sage.misc.c3_controlled
Failed example:
x.mro == x.mro_standard
Exception raised:
Traceback (most recent call last):
File "/Users/palmieri/Desktop/Sage_stuff/git/sage/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 681, in _run
self.compile_and_execute(example, compiler, test.globs)
File "/Users/palmieri/Desktop/Sage_stuff/git/sage/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 1105, in compile_and_execute
exec(compiled, globs)
File "<doctest sage.misc.c3_controlled[53]>", line 1, in <module>
x.mro == x.mro_standard
File "sage/misc/lazy_attribute.pyx", line 129, in sage.misc.lazy_attribute._lazy_attribute.__get__ (build/cythonized/sage/misc/lazy_attribute.c:1940)
result = self.f(a)
File "sage/misc/c3_controlled.pyx", line 1234, in sage.misc.c3_controlled.HierarchyElement.mro_standard (build/cythonized/sage/misc/c3_controlled.c:6991)
return [self.value] + C3_merge([base.mro_standard for base in bases]+[[base.value for base in bases]])
File "sage/misc/c3_controlled.pyx", line 661, in sage.misc.c3_controlled.C3_merge (build/cythonized/sage/misc/c3_controlled.c:3495)
ValueError: Can not merge the items Category of coalgebras with basis over Rational Field, Category of filtered modules with basis over Rational Field, Category of filtered modules with basis over Rational Field.
**********************************************************************
1 of  59 in sage.misc.c3_controlled
[221 tests, 1 failure, 1.16 s]
----------------------------------------------------------------------
sage -t --long --warn-long 60.3 src/sage/misc/c3_controlled.pyx  # 1 doctest failed


### comment:76 Changed 2 years ago by git

• Commit changed from 1f1f5537d0962571c1adcda05147457ccac58615 to b1e1123bddaa07faef71a550e424b56951c5a979

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

 ​b1e1123 Fixes from John's comments: adding documentation, fixing C3 issue, and renaming signed_tensor -> tensor_signed.

### comment:77 Changed 2 years ago by tscrim

Thank you for taking a look at this and fixing these odds and ends. I appreciate it. Sorry again for taking so long to do this (although I found I did need Nicolas's help quite a bit to get some of the technical things with the categories correct).

I like the suggestion in comment:70, so I implemented that. I think it should be a top-level command as there could be someone who has a graded algebra that does want signed tensor products. I did forget to add the new categories to the reference manual; so I added them. I also fixed the C3 issue by adding a few placeholder classes (I also moved one class to its appropriate file).

### comment:78 Changed 2 years ago by git

• Commit changed from b1e1123bddaa07faef71a550e424b56951c5a979 to d29a86d43cf6376c3ed80bdf2590afbae5503c54

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

 ​d29a86d trac 25603: change signed_tensor to tensor_signed.

### comment:79 Changed 2 years ago by jhpalmieri

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


### comment:80 Changed 2 years ago by git

• Commit changed from d29a86d43cf6376c3ed80bdf2590afbae5503c54 to 8ab6815155a503f972c151ad83d7d2769af236e2

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

 ​8ab6815 Adding more placeholder classes to fix MRO resolution issues.

### comment:81 follow-up: ↓ 84 Changed 2 years ago by tscrim

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.

### comment:82 Changed 2 years ago by 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.

### comment:83 follow-up: ↓ 86 Changed 2 years ago by jhpalmieri

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 ..."?

### comment:84 in reply to: ↑ 81 ; follow-up: ↓ 87 Changed 2 years ago by jhpalmieri

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.

### comment:85 Changed 2 years ago by git

• Commit changed from 0c59b50baa975c13530fcc4fd06b95f2aad954a9 to ccccd8a8aa593d7042497103e1b3e90bd259296e

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.

### comment:86 in reply to: ↑ 83 Changed 2 years ago by tscrim

• Reviewers set to Travis Scrimshaw, John Palmieri

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.

### comment:87 in reply to: ↑ 84 Changed 2 years ago by 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...

### comment:88 Changed 2 years ago by gh-darijgr

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.

### comment:89 follow-up: ↓ 90 Changed 2 years ago by gh-darijgr

--- 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.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
+    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?

Last edited 2 years ago by gh-darijgr (previous) (diff)

### comment:90 in reply to: ↑ 89 ; follow-up: ↓ 91 Changed 2 years ago by jhpalmieri

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.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
**********************************************************************
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
+    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.

### comment:91 in reply to: ↑ 90 ; follow-up: ↓ 95 Changed 2 years ago by tscrim

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.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
+    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.

### comment:92 follow-up: ↓ 93 Changed 2 years ago by gh-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.

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

Where?

Last edited 2 years ago by gh-darijgr (previous) (diff)

### comment:93 in reply to: ↑ 92 Changed 2 years ago by tscrim

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`.

### comment:94 Changed 2 years ago by gh-darijgr

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!

### comment:95 in reply to: ↑ 91 Changed 2 years ago by jhpalmieri

• Reviewers changed from Travis Scrimshaw, John Palmieri to Travis Scrimshaw, John Palmieri, Darij Grinberg

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

### comment:96 Changed 2 years ago by gh-darijgr

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!

### comment:97 Changed 2 years ago by tscrim

• Status changed from needs_review to positive_review

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

### comment:98 Changed 2 years ago by jhpalmieri

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

### comment:99 Changed 2 years ago by vbraun

• Branch changed from public/categories/signed_tensor_products-25603 to ccccd8a8aa593d7042497103e1b3e90bd259296e
• Resolution set to fixed
• Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.