Opened 3 years ago
Closed 2 years ago
#25603 closed enhancement (fixed)
Signed tensor product for graded algebras, coalgebras, etc.
Reported by:  jhpalmieri  Owned by:  

Priority:  major  Milestone:  sage8.9 
Component:  categories  Keywords:  fpsac2019 
Cc:  tscrim, nthiery, cnassau  Merged in:  
Authors:  John Palmieri, Travis Scrimshaw  Reviewers:  Travis Scrimshaw, John Palmieri, Darij Grinberg 
Report Upstream:  N/A  Work issues:  
Branch:  ccccd8a (Commits, GitHub, GitLab)  Commit:  ccccd8a8aa593d7042497103e1b3e90bd259296e 
Dependencies:  Stopgaps: 
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.
Change History (99)
comment:1 Changed 3 years ago by
comment:2 Changed 3 years ago by
 Cc tscrim nthiery added
comment:3 Changed 3 years ago by
 Branch set to u/jhpalmieri/gradedtensor
comment:4 Changed 3 years ago by
 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
Here's an attempt.
comment:6 Changed 3 years ago by
 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
 Cc cnassau added
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
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
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
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
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 followup: ↓ 13 Changed 3 years ago by
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 nongraded 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.
comment:13 in reply to: ↑ 12 Changed 3 years ago by
Replying to ghdarijgr:
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 nongraded 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 followup: ↓ 15 Changed 3 years ago by
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 deltaing 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
Replying to ghdarijgr:
Yeah, that braiding suggestion was probably overkill, sorry.
And if we have
SuperAlgebras
andSuperModules
, 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 deltaing 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
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
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
 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
 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
 Status changed from new to needs_review
comment:21 Changed 3 years ago by
 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
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 nonsuperalgebras as separate methods ("supertensor 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 Hopfalgebra 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
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
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
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 followup: ↓ 27 Changed 3 years ago by
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 b class SuperHopfAlgebrasWithBasis(SuperModulesCategory): 74 74 SI = lambda x: self.sum(c * S(self.monomial(t1)) * self.monomial(t2) 75 75 for ((t1, t2), c) in x.coproduct()) 76 76 77 sign = lambda x, y: (1)**(x.degree() * y.degree())78 79 77 for x in tester.some_elements(): 80 81 # antipode is an antihomomorphism78 x_even = x.even_component() 79 x_odd = x.odd_component() 82 80 for y in tester.some_elements(): 83 tester.assertTrue(S(x) * S(y) == sign(x, y) * S(y * x)) 81 y_even = y.even_component() 82 y_odd = y.odd_component() 83 84 # The antipode is a graded antihomomorphism. 85 tester.assertTrue(S(x_even) * S(y_even) == S(y_even * x_even)) 86 tester.assertTrue(S(x_even) * S(y_odd) == S(y_odd * x_even)) 87 tester.assertTrue(S(x_odd) * S(y_even) == S(y_even * x_odd)) 88 tester.assertTrue(S(x_odd) * S(y_odd) == S(y_odd * x_odd)) 84 89 85 90 # mu * (S # I) * delta == counit * unit 86 91 tester.assertTrue(SI(x) == self.counit(x) * self.one())
Would that be better?
comment:27 in reply to: ↑ 26 Changed 3 years ago by
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.
comment:28 followup: ↓ 29 Changed 3 years ago by
+ 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?
comment:29 in reply to: ↑ 28 Changed 3 years ago by
Replying to ghdarijgr:
+ class TensorProducts(TensorProductsCategory): + """ + The category of algebras with basis constructed by tensor product of super algebras with basisYou 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 isself._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_{n1}) (b_0 tensor b_1 tensor ... tensor b_{n1})
you have to commute b_1
past a_i
for i
between 1 and n1
, 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?
comment:30 followup: ↓ 31 Changed 3 years ago by
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 Hopfalgebra 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
Replying to ghdarijgr:
Oh!! I forgot that a tensor can have several factors... I still don't get the code though. Why
self._sets[0]
andself._sets[1]
, not justself._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 Hopfalgebra 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
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 autocomputing the antipode, and copypaste it into a super version (ConnectedGradedSuperHopfAlgebras
?).
comment:33 Changed 3 years ago by
 Commit changed from 1ac4be42cf527b2fe7368ad588959d34b0fb1a7d to efcb5abbfa75435a4fd63840220de8c33effd8a1
comment:34 Changed 3 years ago by
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
comment:36 Changed 3 years ago by
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
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 followup: ↓ 39 Changed 3 years ago by
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.
comment:39 in reply to: ↑ 38 ; followup: ↓ 40 Changed 3 years ago by
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
inhopf_algebras.py
have asuper_categories
method, as compared toSuperAlgebras
which has anextra_super_categories
method? Which should I use forSuperHopfAlgebras
? Which forSuperHopfAlgebrasWithBasis
?
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 theParentMethods
section makes no difference, not that I understand why it would. Note also that inhopf_algebra.py
,def dual
is not inParentMethods
. 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 onsuper_algebras.py
:class SuperCoalgebras(SuperModulesCategory): def extra_super_categories(self): return [self.base_category().Graded()]I also modified
coalgebras.py
by removing theclass 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
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 inParentMethods
becomes a method for anyParent
object in that category (e.g., an exterior algebra). I misread your previous post; so yes, I agree that what you have above should beTrue
.
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 onsuper_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 followup: ↓ 42 Changed 3 years ago by
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 supercommutative
. 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
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 axiomsupercommutative
. Then forSuperCommutativeAlgebras
, 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 followup: ↓ 45 Changed 3 years ago by
This sounds great. I'm glad you are taking this up because I'd like it for #25163.
Can you clarify what the supercommutative
axiom will mean (I can also be patient and see what you have in mind)? Are you saying that an algebra is supercommutative
if fg = (1)^x gf
for elements f
and g
?
comment:44 followup: ↓ 46 Changed 3 years ago by
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 nonsupercommutative 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
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
supercommutative
axiom will mean (I can also be patient and see what you have in mind)? Are you saying that an algebra issupercommutative
iffg = (1)^x gf
for elementsf
andg
?
Yes, that is correct. Is there some other notion of supercommutative that I/we should be worried about?
comment:46 in reply to: ↑ 44 ; followup: ↓ 47 Changed 3 years ago by
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 nonsupercommutative 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
Replying to tscrim:
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 nonsupercommutative 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
 Milestone changed from sage8.3 to sage8.8
 Status changed from needs_review to needs_work
red branch
comment:49 Changed 2 years ago by
 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
 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
 Branch changed from u/jhpalmieri/gradedtensor to public/ticket/25603
 Commit changed from 67a937c53c073ecdb947a9569061901cf1cede8f to 90b468a585868dea09f52b5928301608274300d2
comment:52 Changed 2 years ago by
 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
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
 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
Here is a doctest.
comment:56 Changed 2 years ago by
Bot is now fully green, thanks. Travis, any opinion on what to do here ?
comment:57 Changed 2 years ago by
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 followup: ↓ 62 Changed 2 years ago by
I'll be at Sagedays, but I am not very up to date on this. I definitely do not like that a superHopf 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 ZZdegree 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
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 followup: ↓ 61 Changed 2 years ago by
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.
comment:61 in reply to: ↑ 60 ; followup: ↓ 64 Changed 2 years ago by
Replying to 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 costbenefit 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
Replying to ghdarijgr:
I definitely do not like that a superHopf 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/2graded (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
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/2graded (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.
SuperHopf algebra with grading, I'd say. I would otherwise call it graded superHopf algebra or graded Hopf superalgebra.
comment:64 in reply to: ↑ 61 Changed 2 years ago by
Replying to jhpalmieri:
Replying to 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 costbenefit 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
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.
comment:66 Changed 2 years ago by
 Milestone changed from sage8.8 to sage8.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
 Branch changed from public/ticket/25603 to public/categories/signed_tensor_products25603
 Commit changed from b77c592c59aefe18478d18b371fb9f7ece2ca19a to 3ffd801a50d4ef882a97bee4359e33053b584b0c
 Keywords fpsac2019 added
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.

comment:68 Changed 2 years ago by
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/sage8.9.beta2/src/bin/sageruntests", line 179, in <module> err = DC.run() File "/Users/palmieri/Desktop/Sage_stuff/sage_builds/PYTHON3/sage8.9.beta2/local/lib/python3.7/sitepackages/sage/doctest/control.py", line 1232, in run self.run_doctests() File "/Users/palmieri/Desktop/Sage_stuff/sage_builds/PYTHON3/sage8.9.beta2/local/lib/python3.7/sitepackages/sage/doctest/control.py", line 933, in run_doctests self.dispatcher.dispatch() File "/Users/palmieri/Desktop/Sage_stuff/sage_builds/PYTHON3/sage8.9.beta2/local/lib/python3.7/sitepackages/sage/doctest/forker.py", line 2010, in dispatch self.parallel_dispatch() File "/Users/palmieri/Desktop/Sage_stuff/sage_builds/PYTHON3/sage8.9.beta2/local/lib/python3.7/sitepackages/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/sage8.9.beta2/local/lib/python3.7/sitepackages/sage/doctest/forker.py", line 2193, in start super(DocTestWorker, self).start() File "/Users/palmieri/Desktop/Sage_stuff/sage_builds/PYTHON3/sage8.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/sage8.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/sage8.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/sage8.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/sage8.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/sage8.9.beta2/local/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap self.run() File "/Users/palmieri/Desktop/Sage_stuff/sage_builds/PYTHON3/sage8.9.beta2/local/lib/python3.7/sitepackages/sage/doctest/forker.py", line 2149, in run task(self.options, self.outtmpfile, msgpipe, self.result_queue) File "/Users/palmieri/Desktop/Sage_stuff/sage_builds/PYTHON3/sage8.9.beta2/local/lib/python3.7/sitepackages/sage/doctest/forker.py", line 2487, in __call__ doctests, extras = self._run(runner, options, results) File "/Users/palmieri/Desktop/Sage_stuff/sage_builds/PYTHON3/sage8.9.beta2/local/lib/python3.7/sitepackages/sage/doctest/forker.py", line 2536, in _run result = runner.run(test) File "/Users/palmieri/Desktop/Sage_stuff/sage_builds/PYTHON3/sage8.9.beta2/local/lib/python3.7/sitepackages/sage/doctest/forker.py", line 879, in run return self._run(test, compileflags, out) File "/Users/palmieri/Desktop/Sage_stuff/sage_builds/PYTHON3/sage8.9.beta2/local/lib/python3.7/sitepackages/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/sage8.9.beta2/local/lib/python3.7/sitepackages/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/sage8.9.beta2/local/lib/python3.7/sitepackages/sage/categories/supercommutative_algebras.py", line 97, in _test_supercommutativity * (y * x)) File "/Users/palmieri/Desktop/Sage_stuff/sage_builds/PYTHON3/sage8.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/sage8.9.beta2/local/lib/python3.7/warnings.py", line 110, in _showwarnmsg msg.file, msg.line) : DeprecationWarning: Please use assertEqual instead. ********************************************************************** 1 item had failures: 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
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 b class SignedTensorProductFunctor(CovariantFunctorialConstruction): 39 39 of ``Algebras(QQ).Graded()``. This nested class is itself a subclass of 40 40 :class:`~sage.categories.signed_tensor.SignedTensorProductsCategory`. 41 41 42 EXAMPLES:: 43 44 sage: signed_tensor 45 The signed tensor functorial construction 46 42 47 TESTS:: 43 48 44 49 sage: TestSuite(signed_tensor).run() … … class SignedTensorProductFunctor(CovariantFunctorialConstruction): 60 65 return "The signed tensor functorial construction" 61 66 62 67 signed_tensor = SignedTensorProductFunctor() 63 """64 The signed tensor product functorial construction.65 66 See :class:`~sage.categories.signed_tensor.SignedTensorProductFunctor`67 for more information.68 69 EXAMPLES::70 71 sage: signed_tensor72 The signed tensor functorial construction73 """74 68 75 69 class SignedTensorProductsCategory(CovariantConstructionCategory): 76 70 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
Should signed_tensor
be a toplevel 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 tabcompletion?
comment:71 Changed 2 years ago by
 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
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
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
 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
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/sitepackages/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/sitepackages/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) raise ValueError("Can not merge the items %s."%', '.join([repr(head) for head in heads])) 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 item had failures: 1 of 59 in sage.misc.c3_controlled [221 tests, 1 failure, 1.16 s]  sage t long warnlong 60.3 src/sage/misc/c3_controlled.pyx # 1 doctest failed
comment:76 Changed 2 years ago by
 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
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 toplevel 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
 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
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
 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 followup: ↓ 84 Changed 2 years ago by
comment:82 Changed 2 years ago by
 Commit changed from 8ab6815155a503f972c151ad83d7d2769af236e2 to 0c59b50baa975c13530fcc4fd06b95f2aad954a9
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 followup: ↓ 86 Changed 2 years ago by
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 ; followup: ↓ 87 Changed 2 years ago by
Replying to tscrim:
I fixed the MRO issue by adding some more placeholder classes for graded/filtered vector spaces. This fixes #15475 and #20896.
Are those actually still problems? I tried the examples in the ticket descriptions, and they work in vanilla 8.9.beta2. An example from one of darij's comments is indeed fixed by this, I think.
comment:85 Changed 2 years ago by
 Commit changed from 0c59b50baa975c13530fcc4fd06b95f2aad954a9 to ccccd8a8aa593d7042497103e1b3e90bd259296e
comment:86 in reply to: ↑ 83 Changed 2 years ago by
 Reviewers set to Travis Scrimshaw, John Palmieri
Replying to jhpalmieri:
I think this looks good, but I'm going to keep banging away at it for a few days.
Thank you.
 This is probably overkill, but in characteristic 2, would it make sense to automatically convert super > graded (over Z/2), since there are no signs involved? Probably not worth it, but in characteristic 2, exterior algebras are honest Hopf algebras, as is the mod 2 Steenrod algebra.
Perhaps this would not be bad to add, but I am a little worried about mucking with the extra_super_categories()
too much at this point. So I think it would be good for a followup ticket as I might have already rolled too much into here (i.e., the (super)(co)commutative axioms).
 Why this asymmetry?
sage: AlgebrasWithBasis(QQ).Super().super_categories() [Category of graded algebras with basis over Rational Field, Category of super algebras over Rational Field, Category of super modules with basis over Rational Field] sage: CoalgebrasWithBasis(QQ).Super().super_categories() [Category of super modules with basis over Rational Field, Category of coalgebras with basis over Rational Field, Category of super coalgebras over Rational Field]Should "Category of *graded* coalgebras with basis ..." be among the super categories in the second case, rather than just "Category of coalgebras with basis ..."?
That was a bug. Good catch. I forgot to add the extra_super_categories
for that class.
comment:87 in reply to: ↑ 84 Changed 2 years ago by
Replying to jhpalmieri:
Replying to tscrim:
I fixed the MRO issue by adding some more placeholder classes for graded/filtered vector spaces. This fixes #15475 and #20896.
Are those actually still problems? I tried the examples in the ticket descriptions, and they work in vanilla 8.9.beta2. An example from one of darij's comments is indeed fixed by this, I think.
Curiously enough with this branch, I am actually getting back the behavior on that comment. So something very subtle is going on, but the MRO issue seems to still be resolved. The reason why I mentioned those tickets was because the MRO issue reminded me of them, but that seems to be a red herring. Curious...
comment:88 Changed 2 years ago by
The can of superworms has just been reopened on MathOverflow?: https://mathoverflow.net/questions/335889/hopfstructureontheuniversalenvelopingofasuperhopfalgebra
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 supertensors, even at the level of elements. }
comment:89 followup: ↓ 90 Changed 2 years ago by
 a/src/sage/algebras/clifford_algebra.py +++ b/src/sage/algebras/clifford_algebra.py  cat = HopfAlgebrasWithBasis(R).Super().FiniteDimensional() + cat = HopfAlgebrasWithBasis(R).FiniteDimensional().Supercommutative().Supercocommutative()
Are you sure it shouldn't be "HopfSuperAlgebrasWithBasis?(R)"?
 a/src/sage/algebras/steenrod/steenrod_algebra.py +++ b/src/sage/algebras/steenrod/steenrod_algebra.py  from sage.categories.graded_hopf_algebras_with_basis import GradedHopfAlgebrasWithBasis + from sage.categories.super_hopf_algebras_with_basis import SuperHopfAlgebrasWithBasis
I see the existence of a Zgrading (as opposed to just as a Z/2grading) 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 finitedimensional.)
 a/src/sage/categories/coalgebras.py +++ b/src/sage/categories/coalgebras.py + class Cocommutative(CategoryWithAxiom_over_base_ring): + """ + Category of cocommutative coalgebras. + """
Is this class meant to be completely empty as it currently stands?
+ class SubcategoryMethods: + @cached_method + def Supercocommutative(self): + r""" + Return the full subcategory of the supercocommutative + objects of ``self``.
This seems to be in the Coalgebras class. But it only makes sense for supercoalgebras. Are we trying to cause spooky action at a distance here?
 a/src/sage/categories/graded_algebras_with_basis.py +++ b/src/sage/categories/graded_algebras_with_basis.py + class SignedTensorProducts(SignedTensorProductsCategory): + """ + The category of algebras with basis constructed by signed tensor + product of algebras with basis. + """
The word "super", or at least "graded", should probably fall somewhere here.
Can you add doctests verifying that SuperBialgebras? are not a subcat of Bialgebras, supercommutative superalgebras are not commutative algebras, and same for supercoalgebras?
comment:90 in reply to: ↑ 89 ; followup: ↓ 91 Changed 2 years ago by
Replying to ghdarijgr:
I can't answer any of the design questions, so I hope Travis will respond, too.
 a/src/sage/algebras/clifford_algebra.py +++ b/src/sage/algebras/clifford_algebra.py  cat = HopfAlgebrasWithBasis(R).Super().FiniteDimensional() + cat = HopfAlgebrasWithBasis(R).FiniteDimensional().Supercommutative().Supercocommutative()Are you sure it shouldn't be "HopfSuperAlgebrasWithBasis?(R)"?
The "Supercommutative" and "Supercocommutative" axioms imply "Super" Hopf algebra, so is this necessary?
 a/src/sage/algebras/steenrod/steenrod_algebra.py +++ b/src/sage/algebras/steenrod/steenrod_algebra.py  from sage.categories.graded_hopf_algebras_with_basis import GradedHopfAlgebrasWithBasis + from sage.categories.super_hopf_algebras_with_basis import SuperHopfAlgebrasWithBasisI see the existence of a Zgrading (as opposed to just as a Z/2grading) 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 Zgrading (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 finitedimensional.)
At least with the Steenrod algebra, there is a method homogeneous_component
which takes a degree as input and returns the finite dimensional vector space, with basis, for the component in that degree.
 a/src/sage/categories/coalgebras.py +++ b/src/sage/categories/coalgebras.py + class Cocommutative(CategoryWithAxiom_over_base_ring): + """ + Category of cocommutative coalgebras. + """Is this class meant to be completely empty as it currently stands?
+ class SubcategoryMethods: + @cached_method + def Supercocommutative(self): + r""" + Return the full subcategory of the supercocommutative + objects of ``self``.This seems to be in the Coalgebras class. But it only makes sense for supercoalgebras. Are we trying to cause spooky action at a distance here?
I tried deleting this and got a few doctest failures:
********************************************************************** File "src/sage/categories/coalgebras.py", line 262, in sage.categories.coalgebras.Coalgebras.Super.SubcategoryMethods.Supercocommutative Failed example: Coalgebras(ZZ).WithBasis().Super().Supercocommutative() Expected: Category of supercocommutative super coalgebras with basis over Integer Ring Got: Category of super coalgebras with basis over Integer Ring ********************************************************************** File "src/sage/categories/coalgebras.py", line 264, in sage.categories.coalgebras.Coalgebras.Super.SubcategoryMethods.Supercocommutative Failed example: BialgebrasWithBasis(QQ).Super().Supercocommutative() Expected: Join of Category of super algebras with basis over Rational Field and Category of super bialgebras over Rational Field and Category of super coalgebras with basis over Rational Field and Category of supercocommutative super coalgebras over Rational Field Got: Join of Category of super algebras with basis over Rational Field and Category of super bialgebras over Rational Field and Category of super coalgebras with basis over Rational Field ********************************************************************** 1 item had failures: 2 of 4 in sage.categories.coalgebras.Coalgebras.Super.SubcategoryMethods.Supercocommutative [70 tests, 2 failures, 0.40 s]  sage t src/sage/categories/coalgebras.py # 2 doctests failed 
I like the output from those doctests, so I wouldn't want to just delete the class and modify the doctests.
 a/src/sage/categories/graded_algebras_with_basis.py +++ b/src/sage/categories/graded_algebras_with_basis.py + class SignedTensorProducts(SignedTensorProductsCategory): + """ + The category of algebras with basis constructed by signed tensor + product of algebras with basis. + """The word "super", or at least "graded", should probably fall somewhere here.
Can you add doctests verifying that SuperBialgebras? are not a subcat of Bialgebras, supercommutative superalgebras are not commutative algebras, and same for supercoalgebras?
I agree that this would be a good idea.
comment:91 in reply to: ↑ 90 ; followup: ↓ 95 Changed 2 years ago by
Replying to jhpalmieri:
Replying to ghdarijgr:
I can't answer any of the design questions, so I hope Travis will respond, too.
Thank you for answering. I just forgot to do that yesterday. ^^;;
 a/src/sage/algebras/clifford_algebra.py +++ b/src/sage/algebras/clifford_algebra.py  cat = HopfAlgebrasWithBasis(R).Super().FiniteDimensional() + cat = HopfAlgebrasWithBasis(R).FiniteDimensional().Supercommutative().Supercocommutative()Are you sure it shouldn't be "HopfSuperAlgebrasWithBasis?(R)"?
The "Supercommutative" and "Supercocommutative" axioms imply "Super" Hopf algebra, so is this necessary?
As John said, the implication is already there. So adding Super
to the first category is overkill.
 a/src/sage/algebras/steenrod/steenrod_algebra.py +++ b/src/sage/algebras/steenrod/steenrod_algebra.py  from sage.categories.graded_hopf_algebras_with_basis import GradedHopfAlgebrasWithBasis + from sage.categories.super_hopf_algebras_with_basis import SuperHopfAlgebrasWithBasisI see the existence of a Zgrading (as opposed to just as a Z/2grading) 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, becauseGradedSuperHopfAlgebras...
is redundant: super implies graded, and "graded" should make no assumptions about what the grading group is. You could haveGradedConnectedSuperHopfAlgebras...
because graded + connected implies a Zgrading (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 finitedimensional.)
At least with the Steenrod algebra, there is a method
homogeneous_component
which takes a degree as input and returns the finite dimensional vector space, with basis, for the component in that degree. a/src/sage/categories/coalgebras.py +++ b/src/sage/categories/coalgebras.py + class Cocommutative(CategoryWithAxiom_over_base_ring): + """ + Category of cocommutative coalgebras. + """Is this class meant to be completely empty as it currently stands?
Yes because we cannot do anything special with them other than mark them at this point. Although we could add a test for cocommutative coalgebras with basis to check that it is cocommutative.
+ class SubcategoryMethods: + @cached_method + def Supercocommutative(self): + r""" + Return the full subcategory of the supercocommutative + objects of ``self``.This seems to be in the Coalgebras class. But it only makes sense for supercoalgebras. Are we trying to cause spooky action at a distance here?
I tried deleting this and got a few doctest failures: [snip] I like the output from those doctests, so I wouldn't want to just delete the class and modify the doctests.
So should supercommutative only be there for algebras? In both cases, it is just a convenience method to shortcut doing Algebras(QQ).Super().Supercommutative()
and similarly for coalgebras. 1 for removing them.
 a/src/sage/categories/graded_algebras_with_basis.py +++ b/src/sage/categories/graded_algebras_with_basis.py + class SignedTensorProducts(SignedTensorProductsCategory): + """ + The category of algebras with basis constructed by signed tensor + product of algebras with basis. + """The word "super", or at least "graded", should probably fall somewhere here.
Yes, I just forgot to change this when I moved it. Feel free to add.
Can you add doctests verifying that SuperBialgebras? are not a subcat of Bialgebras, supercommutative superalgebras are not commutative algebras, and same for supercoalgebras?
I agree that this would be a good idea.
This already is there and was added as per your request when we first did the super stuff; see coalgebras.py
. For the commutative, we already are explicitly forbidding commutative to be passed; see super_modules.py
. So adding more tests of this form is redundant IMO.
comment:92 followup: ↓ 93 Changed 2 years ago by
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?
comment:93 in reply to: ↑ 92 Changed 2 years ago by
Replying to ghdarijgr:
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 240249 of coalgebras.py
.
comment:94 Changed 2 years ago by
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 240249 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
 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
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
 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
Thank you, Travis, for implementing this in a way that makes everyone happy, too!
comment:99 Changed 2 years ago by
 Branch changed from public/categories/signed_tensor_products25603 to ccccd8a8aa593d7042497103e1b3e90bd259296e
 Resolution set to fixed
 Status changed from positive_review to closed
See https://groups.google.com/forum/#!topic/sagedevel/8broUYQ0p7c/discussion for one bug which could be fixed by implementing this.