New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Signed tensor products does not allow tensor products with non-signed modules #31266
Comments
New commits:
|
Commit: |
comment:2
I'm confused about why Sage is trying to use a signed tensor product in characteristic 2 in the first place. |
comment:3
Replying to @jhpalmieri:
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. |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:5
Replying to @tscrim:
-1=1 in characteristic 2, so the sign doesn't matter. |
comment:6
Replying to @jhpalmieri:
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
Because the signs don't matter, the following should return True:
whereas this should be false (as it is) in other characteristics. Maybe this should return True as well:
Not for this ticket, though. |
Reviewer: John Palmieri |
comment:8
The change looks okay to me, but every time I look at tensor products in Sage, I get confused. The documentation for
So it's not clear that it should be used with elements in the first place. In this case, Actually, I take that back, I'm not happy with the change. You're modifying |
comment:9
Replying to @jhpalmieri:
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
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 |
comment:10
Possibly related discussion: #30373. |
comment:11
If it is intentional that |
comment:12
Replying to @jhpalmieri:
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
Okay, let's move on. |
comment:14
Replying to @jhpalmieri:
Thank you. I created #31272 for improving the documentation. |
comment:15
For what it's worth,
I'm not sure what policy is being discussed, but maybe it's this one. |
comment:16
I am not sure either. The person to ask is most likely Nicolas. |
Changed branch from public/categories/super_tensor_non_super-31266 to |
Reported on https://ask.sagemath.org/question/55365:
If this happens we should fall back on the usual tensor product.
CC: @egourgoulhon @mjungmath @jhpalmieri @mkoeppe @slel @nthiery
Component: categories
Keywords: signed tensor products
Author: Travis Scrimshaw
Branch/Commit:
f2a58a8
Reviewer: John Palmieri
Issue created by migration from https://trac.sagemath.org/ticket/31266
The text was updated successfully, but these errors were encountered: