#31266 closed defect (fixed)

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

Reported by: tscrim Owned by:
Priority: major Milestone: sage-9.3
Component: categories Keywords: signed tensor products
Cc: egourgoulhon, gh-mjungmath, jhpalmieri, mkoeppe, slelievre, nthiery Merged in:
Authors: Travis Scrimshaw Reviewers: John Palmieri
Report Upstream: N/A Work issues:
Branch: f2a58a8 (Commits, GitHub, GitLab) Commit: f2a58a8eb3ab60cbbd5cd1060674e3f1e961eab8
Dependencies: Stopgaps:

Status badges

Description

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.

Change History (17)

comment:1 Changed 11 months ago by tscrim

  • Branch set to public/categories/super_tensor_non_super-31266
  • Commit set to a17c49db9a77315c2c154939f018a45271fb5472
  • Status changed from new to needs_review

New commits:

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

comment:2 follow-up: Changed 11 months ago by jhpalmieri

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

comment:3 in reply to: ↑ 2 ; follow-up: Changed 11 months ago by 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.

comment:4 Changed 11 months ago by git

  • Commit changed from a17c49db9a77315c2c154939f018a45271fb5472 to f2a58a8eb3ab60cbbd5cd1060674e3f1e961eab8

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

f2a58a8Changing test to be characteristic 3.

comment:5 in reply to: ↑ 3 ; follow-up: Changed 11 months ago by 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.

comment:6 in reply to: ↑ 5 Changed 11 months ago by 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.

comment:7 Changed 11 months ago by 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.

comment:8 follow-up: Changed 11 months ago by jhpalmieri

  • Reviewers set to John Palmieri

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?

comment:9 in reply to: ↑ 8 Changed 11 months ago by 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).

comment:10 Changed 11 months ago by slelievre

  • Cc egourgoulhon gh-mjungmath mkoeppe added

Possibly related discussion: #30373.

comment:11 follow-up: Changed 11 months ago by 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.

comment:12 in reply to: ↑ 11 Changed 11 months ago by 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.

comment:13 follow-up: Changed 11 months ago by jhpalmieri

  • Status changed from needs_review to positive_review

Okay, let's move on.

comment:14 in reply to: ↑ 13 Changed 11 months ago by tscrim

Replying to jhpalmieri:

Okay, let's move on.

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

comment:15 Changed 11 months ago by 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 for elements 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.

Last edited 11 months ago by jhpalmieri (previous) (diff)

comment:16 Changed 11 months ago by tscrim

  • Cc nthiery added

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

comment:17 Changed 10 months ago by vbraun

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