Twisting in tensor products

[feec4a95-982d-477f-8e7d-ac16e371035a]

The tensor product of cohomology rings of product of two spaces is twisted in the following sense:

(a ⊗ b) ⌣ (c ⊗ d) = (-1)^|b|·|c|(a ⌣ c)⊗(b ⌣ d)

However there is no way to inform sage of this twisting at the moment:

S_2 = delta_complexes.SurfaceOfGenus(2);
H = S_2.cohomology_ring(QQ);
H2 = tensor([H,H]); 

In H2 the multiplication is the non-twisted one.

maybe tensor([H,H], twisted=True) could be introduced.

CC: @tscrim @jhpalmieri @nthiery @darijgr

Component: algebraic topology

Keywords: tensor product, cohomology

Branch/Commit: u/kalmar/twisting_in_tensor_products @ e7e9895

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

[tscrim]

comment:1

So for this, the tensor creates an instance of sage.combinat.free_module.CombinatorialFreeModule_Tensor, which is in the category

sage: H2.category()
Category of finite dimensional tensor products of algebras with basis over Rational Field

Now the easiest way out would be creating a class for the tensor product of two homology spaces (which could be something we might want anyways) that inherits from CombinatorialFreeModule_Tensor and overrides product_on_basis (which comes from the category).

Another approach that is more work, but much more gratifying (and something we need to do) is changing around the categories. In particular, from Hatcher, the cohomology over a commutative ring is a commutative superalgebra. So we would need to change its category:

sage: H.category()
Category of finite dimensional graded algebras with basis over Rational Field

Then we would need to create a category of tensor products of commutative superalgebras with a default (twisted) multiplication.

I'm more for doing option 2, but it could have some technical issues that we might have to work through as well. I'll leave the choice up to you.

[feec4a95-982d-477f-8e7d-ac16e371035a]

comment:2

Ok, I'm fine with both ways (the second seems more future proof, so that would be my personal choice).

The only problem is that I have very little idea about sage type theory... err.. the categorical background behind sage objects ;-)

looking at superalgebras definition (acutally never heard of) Clifford algebras are also the natural examples.

So: where can I learn about category structures as implemented in sage?

[tscrim]

comment:3

Replying to @sagetrac-kalmar:

Ok, I'm fine with both ways (the second seems more future proof, so that would be my personal choice).

The only problem is that I have very little idea about sage type theory... err.. the categorical background behind sage objects ;-)

So: where can I learn about category structures as implemented in sage?

In the src/sage/categories/ folder is where the source code is. There's a detailed description of Sage's category framework here. Simon King's tutorial is more on creating parents and elements, so doesn't quite apply.

One of the easiest ways to start working on this would be to copy code from elsewhere in Sage. I would probably mimic what is done in sage/categories/algebras.py first (don't forget to also add the imports).

looking at superalgebras definition (acutally never heard of) Clifford algebras are also the natural examples.

Yes, Clifford algebras are the standard examples of superalgebras. Exterior algebras (which are a special case of Clifford algebras) and their generalizations of C(D)GA (Commutative (Differential) Graded Algebras) are also another class of good examples.

[feec4a95-982d-477f-8e7d-ac16e371035a]

comment:4

Sorry that I dropped, I had shit-load of work on other projects (I still do, but I'm sick of them);

I see (in master) that You did introduced code for SuperAlgebras and SuperModules;

If I still want to work on the thing, is there something I can help?

[tscrim]

comment:5

The first thing we need to do is put the cohomology ring in the category of graded commutative superalgebras (we currently have a restricting the base ring is a field). The second would be implementing a category of TensorProducts for superalgebras with a product_on_basis method analogous for that of AlgebrasWithBasis in SuperalgebrasWithBasis.

[feec4a95-982d-477f-8e7d-ac16e371035a]

comment:6

It looks that it would be nice to have SuperAlgebrasWithBasis.example();

Also I think something should be put to cohomology documentation as a (test case?) that the tensor-product of cohomologies (e.g. H¹(S¹)⊗H¹(S¹)) respects the anticommutativity present in (i.e. H¹(S¹×S¹)).

What do You think?

Below is the very first try; For now without any docs.

Putting cohomology rings in the category of graded commutative superalgebras:

diff --git a/src/sage/homology/homology_vector_space_with_basis.py b/src/sage/homology/homology_vector_space_with_basis.py
index 3835e13..17597bc 100644
--- a/src/sage/homology/homology_vector_space_with_basis.py
+++ b/src/sage/homology/homology_vector_space_with_basis.py
@@ -435,7 +435,7 @@ class CohomologyRing(HomologyVectorSpaceWithBasis):
             sage: H = RP2.cohomology_ring(GF(5))
             sage: TestSuite(H).run()
         """
-        cat = Algebras(base_ring).WithBasis().Graded().FiniteDimensional()
+        cat = Superalgebras(base_ring).WithBasis().Graded().FiniteDimensional()
         HomologyVectorSpaceWithBasis.__init__(self, base_ring, cell_complex, True, cat)

     def _repr_(self):

For the second:

diff --git a/src/sage/categories/super_algebras_with_basis.py b/src/sage/categories/super_algebras_with_basis.py
index 9a4a1bc..198ec04 100644
--- a/src/sage/categories/super_algebras_with_basis.py
+++ b/src/sage/categories/super_algebras_with_basis.py
@@ -59,3 +59,22 @@ class SuperAlgebrasWithBasis(SuperModulesCategory):
             from sage.algebras.associated_graded import AssociatedGradedAlgebra
             return AssociatedGradedAlgebra(self)

+        class TensorProducts(TensorProductsCategory):
+        """
+        The category of superalgebras with basis constructed by tensor product of superalgebras with basis
+        """
+
+        class ParentMethods:
+            """
+            implements operations on tensor products of superalgebras with basis
+            """
+
+            def product_on_basis(self, t1, t2):
+                """
+                The product of the superalgebra on the basis, as per
+                ``SuperalgebrasWithBasis.ParentMethods.product_on_basis``.
+                """
+
+                l = (module.monomial(x1)*module.monomial(x2) for (module, x1, x2) in zip(self._sets, t1, t2))
+
+                return (-1)^(x1.degree()*x2.degree())*tensor(l)

[tscrim]

comment:7

The second looks good, but for the first, you should also add .Commutative().

It looks that it would be nice to have SuperAlgebrasWithBasis.example();

I think having a Superalgebras(R).example() should be done as a separate ticket (but +1 to doing it).

Also I think something should be put to cohomology documentation as a (test case?) that the tensor-product of cohomologies (e.g. H¹(S¹)⊗H¹(S¹)) respects the anticommutativity present in (i.e. H¹(S¹×S¹)).

+1 to adding such an example to the cohomology ring doc.

[feec4a95-982d-477f-8e7d-ac16e371035a]

comment:8

Then why is Commutative commented from axiom_whitelist in super_modules.py?

I know it is a matter of convention (CDGAs are commutative, where we mean graded anitcommutativity, etc.), so what does actually the axiom_list mean?

Does Algebras(R).Commutative() mean something else than Algebras(R).Graded().Commutative() (as it should?) Where can one find out?

[tscrim]

comment:9

We do not want to automatically pass commutativity for precisely the reason you mentioned (although replace Graded() by Super()): the forgetful functor from superalgebras to algebras does not preserve the commutative axiom. It makes it so that if you really meant a commutative superalgebra, you must do Algebras(R).Super().Commutative(), not Algebras(R).Commutative().Super() (did you want it to be commutative as an algebra or as a superalgebra?).

[feec4a95-982d-477f-8e7d-ac16e371035a]

comment:10

ok, thanks;

Maybe the last question before I sit back to work:

• CohomologyRing now became Superalgebras(base_ring).WithBasis().Graded().FiniteDimensional().Commutative() However Superalgebras.extra_super_categories() returns Graded() as well. Isn't then .Graded() in the list above superfluous (as already implied by Superalgebras)?

[tscrim]

comment:11

You are correct, it is superfluous. However, it gives a visual cue to anyone looking at the code that the grading we want is not the (natural) Z₂ grading.

[feec4a95-982d-477f-8e7d-ac16e371035a]

comment:12

Ok, I'm struggling with yet another problem:

To confirm that cohomology rings are recognized as super:

sage: S_2 = delta_complexes.SurfaceOfGenus(1);
sage: H = S_2.cohomology_ring();
sage: H.category()
Join of 
Category of graded algebras with basis over Rational Field and 
Category of finite dimensional algebras with basis over Rational Field and 
Category of super algebras over Rational Field and 
Category of commutative algebras over Rational Field

Yet tensor product of those is not a super algebra (I also checked .categories():

sage: H2 = H.tensor(H);
sage: H2.category()
Category of finite dimensional tensor products of algebras with basis over Rational Field

I thought it's enough to add

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

to SuperAlgebrasWithBasis.TensorProducts, to make sage recognize tensor product of super algebras as a super algebra. It does so on the category level:

sage: SuperAlgebrasWithBasis(QQ).TensorProducts().super_categories()
[Category of super algebras with basis over Rational Field,
 Category of tensor products of algebras with basis over Rational Field]

Cool. Yet the example as above still fails to live up to category of super algebras; I also checked that H2.product_on_basis points to the method from the category of algebras;

What am I missing??

[tscrim]

comment:13

There are subtleties with the WithBasis and Graded constructions:

sage: type(Algebras(QQ).WithBasis().Graded())
<class 'sage.categories.graded_algebras_with_basis.GradedAlgebrasWithBasis_with_category'>
sage: type(Algebras(QQ).Graded().WithBasis())
<class 'sage.categories.category.JoinCategory_with_category'>

The former is the correct order: algebras that have a distinguished basis and that basis is graded (the other is algebras that are graded that have a distinguished basis, not necessarily graded). So, the order of Super().WithBasis().Graded() is correct and the Graded() is actually not superfluous on second thought.

What we probably need to do is create a little stub category like GradedSuperalgebrasWithBasis similar to GradedAlgebrasWithBasis. We probably also need an another CategoryWithAxiom called Commutative of Superalgebras(WithBasis). I can take care of this if you want me to (if so, please push your current branch so I can work off of that).

[feec4a95-982d-477f-8e7d-ac16e371035a]

comment:14

I would be happy to learn more the category framework, by doing this on my own. I have to say that the primer is well, a (draft of) primer, i.e. not very informative e.g. for the task of implementing Your own category.

Graded-non-Graded.

Yep, I understand this distinction, but constructor of SuperAlgebrasWithBasis actually adds .Graded() to categories (in .extra_super_categories). What then this .Graded() in .extra_super_categories mean??

I also wanted to ask this, but thought this is particularly stupid question: I noticed that SuperAlgebrasWithBasis inherit from SuperModulesCategory, whereas AlgebrasWithBasis inherit from CategoryWithAxiom_over_base_ring. Is this related to Your second paragraph (which I don't quite comprehend right now)?

[tscrim]

comment:15

Replying to @sagetrac-kalmar:

I would be happy to learn more the category framework, by doing this on my own. I have to say that the primer is well, a (draft of) primer, i.e. not very informative e.g. for the task of implementing Your own category.

Well, to be fair, this is a much more challenging example of a category construction.

Graded-non-Graded.

Yep, I understand this distinction, but constructor of SuperAlgebrasWithBasis actually adds .Graded() to categories (in .extra_super_categories). What then this .Graded() in .extra_super_categories mean??

It means every superalgebra with basis is (naturally) a graded algebra with basis.

I also wanted to ask this, but thought this is particularly stupid question: I noticed that SuperAlgebrasWithBasis inherit from SuperModulesCategory, whereas AlgebrasWithBasis inherit from CategoryWithAxiom_over_base_ring. Is this related to Your second paragraph (which I don't quite comprehend right now)?

That is because we construct a super algebra from an algebra via a functorial construction (i.e., adding the grading), whereas an algebra is a concrete category created by imposing axioms. It is related to the second paragraph, and is the reasoning why we need a stub category (at least, for the code).

[feec4a95-982d-477f-8e7d-ac16e371035a]

Branch: u/kalmar/twisting_in_tensor_products

[feec4a95-982d-477f-8e7d-ac16e371035a]

comment:17

Ok, just for future readers:

This is a much better resource for learning the category framework.

---

New commits:

82404c6	Make cohomology ring a super algebra
e7e9895	Add product_on_basis override for tensor producs of super algebras

[feec4a95-982d-477f-8e7d-ac16e371035a]

Commit: e7e9895

[tscrim]

comment:18

Yes, sorry for not posting that link (I mixed it up with the primer while I was running around with my busy past week). Let me know if you come across any other problems or when you're ready for me to take a look at (part of) things.

[feec4a95-982d-477f-8e7d-ac16e371035a]

comment:19

If I understand Correctly I have to implement GradedSuperAlgebrasWithBasis as an object of GradedSuperModulesCategory which then should be object of the join of (I mean inherit from both of) (Regressive?)CovariantConstructionCategory and Category_over_base_ring?

If we have this I need to

• add Commutative axiom to both SuperAlgebras and SuperAlgebrasWithBasis, so that (deconstructing call creating cohomology ring) SuperAlgebras(base_ring).WithBasis().Graded().FiniteDimensional().Commutative() constructs
  1. first a (regressive) object of GradedSuperAlgebrasWithBasis, then
  2. (insert some magic here) adds Commutative axiom.

Then the final thing will be an object of CategoryWithAxiom_over_base_ring, i.e. a superalgebra (with presence of basis and grading now "shadowed" by insertion of the axiom Commutative) and therefore call to TensorProduct will finally pick the right category (and product_on_basis()).

Is that correct?

Question no. 1: SuperModulesCategory (super of SuperAlgebrasWithBasis) is not considered Regressive (as GradedModulesCategory is). As far as I understand the goal is to implement e.g. tensor product of superalgebras as a superalgebra, hence SuperAlgebraWithBasis should be considered as Regressive? Is there a need to reflect that in code?

Question no. 2: Implementing the axiom Commutative should I create separate files "commutative_super_algebras.py" with class CommutativeSuperAlgebra(CategoryWithAxiom_over_base_ring), or should I rather implement those as subclasses in super_algebras.py (and similarly for "_with_basis")?

[tscrim]

comment:20

I think most of what you said is correct, but I would need to play with things to see if they actually are correct (or have Nicolas come in and answer). The end point is that the Super should catch the commutative, but behave regressively with respect to the FiniteDimensional.

The answer to question 1 is no because of the commutativity issue. The answer to question 2 is you probably do not need a separate file, although it could be desirable. We should implement a _test_commutativity method similar to _test_associativity, but that doesn't have to be done here.