Signed tensor products does not allow tensor products with non-signed modules

[tscrim]

Reported on ​https://ask.sagemath.org/question/55365:

sage: a = SteenrodAlgebra(2).an_element()
sage: M = CombinatorialFreeModule(GF(2), ['s', 't', 'u'])
sage: s = M.basis()['s']
sage: tensor([a, s])
---------------------------------------------------------------------------
KeyError                                  Traceback (most recent call last)
~/sage/local/lib/python3.8/site-packages/sage/misc/cachefunc.pyx in sage.misc.cachefunc.CachedMethodCaller.__call__ (build/cythonized/sage/misc/cachefunc.c:10303)()
   1942             try:
-> 1943                 return cache[k]
   1944             except TypeError:  # k is not hashable

KeyError: (((Category of supercocommutative super hopf algebras with basis over Finite Field of size 2, Category of finite dimensional vector spaces with basis over Finite Field of size 2),), ())

During handling of the above exception, another exception occurred:

AttributeError                            Traceback (most recent call last)
<ipython-input-5-4fb6e8615dbd> in <module>
----> 1 tensor([a, s])

~/sage/local/lib/python3.8/site-packages/sage/categories/covariant_functorial_construction.py in __call__(self, args, **kwargs)
    221         assert(all( hasattr(arg, self._functor_name) for arg in args))
    222         assert(len(args) > 0)
--> 223         return getattr(args[0], self._functor_name)(*args[1:], **kwargs)
    224 
    225 class FunctorialConstructionCategory(Category): # Should this be CategoryWithBase?

~/sage/local/lib/python3.8/site-packages/sage/categories/modules_with_basis.py in tensor(*elements)
   2105             assert(all(isinstance(element, Element) for element in elements))
   2106             parents = [parent(element) for element in elements]
-> 2107             return tensor(parents)._tensor_of_elements(elements) # good name???
   2108 
   2109     class Homsets(HomsetsCategory):

~/sage/local/lib/python3.8/site-packages/sage/categories/covariant_functorial_construction.py in __call__(self, args, **kwargs)
    221         assert(all( hasattr(arg, self._functor_name) for arg in args))
    222         assert(len(args) > 0)
--> 223         return getattr(args[0], self._functor_name)(*args[1:], **kwargs)
    224 
    225 class FunctorialConstructionCategory(Category): # Should this be CategoryWithBase?

~/sage/local/lib/python3.8/site-packages/sage/categories/super_algebras.py in tensor(*parents, **kwargs)
     85             """
     86             constructor = kwargs.pop('constructor', tensor_signed)
---> 87             cat = constructor.category_from_parents(parents)
     88             return parents[0].__class__.Tensor(parents, category=cat)
     89 
[snip]
~/sage/local/lib/python3.8/site-packages/sage/categories/covariant_functorial_construction.py in category_from_category(self, category)
    191         # TODO: add support for parametrized functors
    192         """
--> 193         return getattr(category, self._functor_category)()
    194 
    195     def _repr_(self):

AttributeError: 'VectorSpaces.WithBasis_with_category' object
 has no attribute 'SignedTensorProducts'

If this happens we should fall back on the usual tensor product.

[tscrim]

New commits:

​a17c49d

Falling back to usual tensor product when there is not a signed tensor product.

[jhpalmieri]

I'm confused about why Sage is trying to use a signed tensor product in characteristic 2 in the first place.

[tscrim]

Replying to jhpalmieri:

I'm confused about why Sage is trying to use a signed tensor product in characteristic 2 in the first place.

We don't do a check for the characteristic 2 case when setting the category. It just by default always puts it in the category of supercommutative Hopf algebras. Does something change mathematically in this case?

I will change the test do work in char 3 so it will have a guaranteed distinction between the two.

[git]

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

​f2a58a8

Changing test to be characteristic 3.

[jhpalmieri]

Replying to tscrim:

Replying to jhpalmieri:

I'm confused about why Sage is trying to use a signed tensor product in characteristic 2 in the first place.

We don't do a check for the characteristic 2 case when setting the category. It just by default always puts it in the category of supercommutative Hopf algebras. Does something change mathematically in this case?

-1=1 in characteristic 2, so the sign doesn't matter.

[tscrim]

Replying to jhpalmieri:

Replying to tscrim:

Replying to jhpalmieri:

I'm confused about why Sage is trying to use a signed tensor product in characteristic 2 in the first place.

We don't do a check for the characteristic 2 case when setting the category. It just by default always puts it in the category of supercommutative Hopf algebras. Does something change mathematically in this case?

-1=1 in characteristic 2, so the sign doesn't matter.

Of course, but I was wondering if there could be some other structural difference, such as it no longer satisfied one of the supercommutative Hopf algebra axioms due to the extra freedom. If the category still makes sense, then I don't see a reason why we shouldn't keep it. Likewise, I don't see a point of making a special-case for characteristic 2 in the tensor construction.

[jhpalmieri]

Because the signs don't matter, the following should return True:

sage: SteenrodAlgebra(2) in HopfAlgebras(GF(2))
False

whereas this should be false (as it is) in other characteristics. Maybe this should return True as well:

sage: GradedHopfAlgebrasWithBasis(GF(2)) == SuperHopfAlgebrasWithBasis(GF(2))
False

Not for this ticket, though.

[jhpalmieri]

The change looks okay to me, but every time I look at tensor products in Sage, I get confused. The documentation for tensor says

   This functor takes a collection of graded algebras (possibly with
   basis) and constructs the signed tensor product of those algebras.
   If this algebra is in a subcategory, say that of
   "Algebras(QQ).Graded()", it is automatically endowed with its
   natural algebra structure, thanks to the category
   "Algebras(QQ).Graded().SignedTensorProducts()" of signed tensor
   products of graded algebras.

So it's not clear that it should be used with elements in the first place. In this case, a.tensor(s) fails without the fix here but works with it, so I am happy with the change, but should the documentation of tensor be changed, or do we want the tensor function to apply only to parents, while the tensor method applies to elements?

Actually, I take that back, I'm not happy with the change. You're modifying tensor inside ParentMethods but applying it to elements. The documentation says "Return the tensor product of the parents," and the previous doctests apply to parents, not elements. Am I missing something?

[tscrim]

Replying to jhpalmieri:

The change looks okay to me, but every time I look at tensor products in Sage, I get confused. The documentation for tensor says

   This functor takes a collection of graded algebras (possibly with
   basis) and constructs the signed tensor product of those algebras.
   If this algebra is in a subcategory, say that of
   "Algebras(QQ).Graded()", it is automatically endowed with its
   natural algebra structure, thanks to the category
   "Algebras(QQ).Graded().SignedTensorProducts()" of signed tensor
   products of graded algebras.

So it's not clear that it should be used with elements in the first place. In this case, a.tensor(s) fails without the fix here but works with it, so I am happy with the change, but should the documentation of tensor be changed, or do we want the tensor function to apply only to parents, while the tensor method applies to elements?

It is a functor, so I would expect it to work on the elements as well. I feel like this is just documenting the parent construction, and while it could be more explicit that it also takes in elements, we would also have to change the tensor functor and likely any of the others in the global namespace for consistency.

Actually, I take that back, I'm not happy with the change. You're modifying tensor inside ParentMethods but applying it to elements. The documentation says "Return the tensor product of the parents," and the previous doctests apply to parents, not elements. Am I missing something?

I think so. We need to construct a parent object in the correct category, and it is in the parent where the category is being selected that the error originates. Perhaps a better test would be on the parents?

There are a few different tensor things here to keep track of too. There is the element tensor method, the parent tensor method, the parent Tensor attribute (which is a class), and the tensor functor (which is what is in the global namespace).

[slelievre]

Possibly related discussion: #30373.

[jhpalmieri]

If it is intentional that tensor([a,b,c]) should work with elements, then I think this should be documented. In that case, maybe just adding a sentence and a few doctests is good enough. I don't know if it is intentional, though. Mathematically, a functor is not automatically going to be defined on elements.

[tscrim]

Replying to jhpalmieri:

If it is intentional that tensor([a,b,c]) should work with elements, then I think this should be documented. In that case, maybe just adding a sentence and a few doctests is good enough. I don't know if it is intentional, though. Mathematically, a functor is not automatically going to be defined on elements.

I think that should be a separate ticket as that is unrelated to the issue here. I strongly believe the tensor functor is meant to work on elements as it is definitely well defined there (and something we use all the time in our daily mathematics). You're right that for more general functors, it might not be defined on elements.

[jhpalmieri]

Okay, let's move on.

[tscrim]

Replying to jhpalmieri:

Okay, let's move on.

Thank you. I created #31272 for improving the documentation.

[jhpalmieri]

For what it's worth, sage/categories/modules_with_basis.py has separate tensor methods for parents and elements. Same with sage/categories/crystals.py. A few other files have just a single tensor method for parents, which I am assuming works for both parents and elements. I don't know if there was any overarching scheme (perhaps a single method wouldn't work for some reason for those two cases?), but it might be good to have a policy. The tensor method in modules_with_basis says in its docstring

FIXME: is this a policy that we want to enforce on all parents?

I'm not sure what policy is being discussed, but maybe it's this one.

[tscrim]

I am not sure either. The person to ask is most likely Nicolas.