Opened 2 years ago
Closed 2 years ago
#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: |
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 2 years ago by
Branch: | → public/categories/super_tensor_non_super-31266 |
---|---|
Commit: | → a17c49db9a77315c2c154939f018a45271fb5472 |
Status: | new → needs_review |
comment:2 follow-up: 3 Changed 2 years ago by
I'm confused about why Sage is trying to use a signed tensor product in characteristic 2 in the first place.
comment:3 follow-up: 5 Changed 2 years ago by
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 2 years ago by
Commit: | a17c49db9a77315c2c154939f018a45271fb5472 → f2a58a8eb3ab60cbbd5cd1060674e3f1e961eab8 |
---|
Branch pushed to git repo; I updated commit sha1. New commits:
f2a58a8 | Changing test to be characteristic 3.
|
comment:5 follow-up: 6 Changed 2 years ago by
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 Changed 2 years ago by
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 2 years ago by
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: 9 Changed 2 years ago by
Reviewers: | → 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 Changed 2 years ago by
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
saysThis 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 oftensor
be changed, or do we want thetensor
function to apply only to parents, while thetensor
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
insideParentMethods
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 2 years ago by
Cc: | egourgoulhon gh-mjungmath mkoeppe added |
---|
Possibly related discussion: #30373.
comment:11 follow-up: 12 Changed 2 years ago by
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 Changed 2 years ago by
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: 14 Changed 2 years ago by
Status: | needs_review → positive_review |
---|
Okay, let's move on.
comment:14 Changed 2 years ago by
Replying to jhpalmieri:
Okay, let's move on.
Thank you. I created #31272 for improving the documentation.
comment:15 Changed 2 years ago by
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.
comment:16 Changed 2 years ago by
Cc: | nthiery added |
---|
I am not sure either. The person to ask is most likely Nicolas.
comment:17 Changed 2 years ago by
Branch: | public/categories/super_tensor_non_super-31266 → f2a58a8eb3ab60cbbd5cd1060674e3f1e961eab8 |
---|---|
Resolution: | → fixed |
Status: | positive_review → closed |
New commits:
Falling back to usual tensor product when there is not a signed tensor product.