Mod 2 (co)homology as a module over the Steenrod algebra #36310
Conversation
duality between homology and cohomology: - new method 'dual' to switch between them - new method 'eval' to evaluate cochains on chains and vice versa - new method '_test_duality' to make sure that our orderings on the bases for homology and cohomology are consistent - "implement" mod 2 Steenrod operations for cubical complexes by converting those complexes to simplicial complexes. Likely very slow.
over the Steenrod algebra. Create a new class, CohomologyRing_mod2, for this, because these Steenrod operations on cohomology are only implemented at the prime 2. Use the new class automatically when users create `K.cohomology_ring(GF(2))` for a complex `K`. Move the existing "Sq" method to the new class, and create new methods to make the module action transparent. Also create a method steenrod_module_map in case (a) someone wants access to these matrices and (b) for future use, and in particular for computing the Steenrod algebra action on homology.
This uses the module structure on cohomology together with vector space dualization to put a module structure on homology. While Sq^n increases dimension in cohomology by n, it lowers homological degree by n.
jhpalmieri
force-pushed
the
cohomology-as-module
branch
from
31993f7
to
9265721
Compare
| if a in self.base_ring(): | ||
| return self.map_coefficients(lambda c: c*a) |
There was a problem hiding this comment.
Is there some reason you are not using the default implementation given by CFM elements for scalars?
There was a problem hiding this comment.
I thought I had tried other things and they hadn't worked. For example I thought that just using return c * self led to an infinite recursion, because * called _acted_upon_. This doesn't seem to be the case, so I must have been confused. I'll change it.
| True | ||
| """ | ||
| # Handle field elements first. | ||
| if a in self.base_ring(): |
There was a problem hiding this comment.
Same comment about going to CFMElement.
There was a problem hiding this comment.
Ah, this is the place where I get the infinite recursion. I think I need to keep this one as is.
There was a problem hiding this comment.
You should be able to do
ret = CombinatorialFreeModule.Element._acted_upon_(self, a, self_on_left)
if ret is not None: # did the scalar action
return retwhich will be a lot faster than the current implementation. If this doing this does get an infinite loop, can you post the traceback? It really shouldn't have such a loop...
jhpalmieri
force-pushed
the
cohomology-as-module
branch
from
9233784
to
cd95bec
Compare
There was a problem hiding this comment.
Two other general comments:
- Can you please squash all of the little commits from the previous review? They are a bit annoying and the messages are worse than useless.
- This is agnostic to the implementation of
$F_2$ , right? So I think we need a more robust test as we have, e.g.,
sage: GF(2) == GF(2, impl='ntl')
FalseI am thinking of instead testing the characteristic and the cardinality. Actually, is this something for any char 2 field or just
| True | ||
| """ | ||
| # Handle field elements first. | ||
| if a in self.base_ring(): |
There was a problem hiding this comment.
You should be able to do
ret = CombinatorialFreeModule.Element._acted_upon_(self, a, self_on_left)
if ret is not None: # did the scalar action
return retwhich will be a lot faster than the current implementation. If this doing this does get an infinite loop, can you post the traceback? It really shouldn't have such a loop...
| """ | ||
| # Handle field elements first. | ||
| if a in self.base_ring(): | ||
| return a * self |
There was a problem hiding this comment.
This wasn't what I had in mind. I was thinking of an explicit super() call (or to the specific base class as indicated in the other comment).
This uses the module structure on cohomology together with vector space dualization to put a module structure on homology. While Sq^n increases dimension in cohomology by n, it lowers homological degree by n. Update src/sage/homology/homology_vector_space_with_basis.py Co-authored-by: Travis Scrimshaw <clfrngrown@aol.com> Update src/sage/homology/homology_vector_space_with_basis.py Co-authored-by: Travis Scrimshaw <clfrngrown@aol.com> Update src/sage/homology/homology_vector_space_with_basis.py Co-authored-by: Travis Scrimshaw <clfrngrown@aol.com> Update src/sage/homology/homology_vector_space_with_basis.py Co-authored-by: Travis Scrimshaw <clfrngrown@aol.com> Update src/sage/homology/homology_vector_space_with_basis.py Co-authored-by: Travis Scrimshaw <clfrngrown@aol.com> Update src/sage/homology/homology_vector_space_with_basis.py Co-authored-by: Travis Scrimshaw <clfrngrown@aol.com> Update src/sage/homology/homology_vector_space_with_basis.py Co-authored-by: Travis Scrimshaw <clfrngrown@aol.com> Update src/sage/homology/homology_vector_space_with_basis.py Co-authored-by: Travis Scrimshaw <clfrngrown@aol.com> Update src/sage/topology/cell_complex.py Co-authored-by: Travis Scrimshaw <clfrngrown@aol.com>
Sure.
This looks like a bug in Sage to me. I can understand why
Just F2. |
jhpalmieri
force-pushed
the
cohomology-as-module
branch
from
cd95bec
to
a4a391d
Compare
jhpalmieri
force-pushed
the
cohomology-as-module
branch
from
a4a391d
to
659a9b2
Compare
Thank you.
It's not a bug, but a feature. Equal-but-not-identical parents are a big pain to deal with, and IMO the less we have the better. I think Also, for the category, you can do |
|
Regarding
I'm not sure what changes you have in mind. The
It's easy to add some computations of cohomology operations, cup products, etc., but I get errors with
|
Perhaps, but I don't really know that code very well. It might be best to put some kind of warning or note about it.
I thought I saw a
Yes, although it looks like you found some bugs that need reporting. I might add these TestSuite calls with skipping those particular tests. |
Actually it looks like I was wrong about this being agnostic about the implementation of |
Maybe I should say "your favorite nonempty simplicial complex," because it looks like the empty complex works okay. |
Actually, now I really need to be persuaded that This is a field over which we cannot do linear algebra? |
|
First, you have an input error as |
I think that to do it right, someone needs to add doctests for the alternate implementations of finite fields that demonstrate that they can do everything in Sage that the default implementations do. That is a big task, but until it happens, why should anyone trust or expect that |
|
These changes seem to fix this particular problem with |
I agree with basically everything you said except the last part. The good news is that it raises an error or crashes rather than return a wrong answer. However, there is more to life than linear algebra (although not much :P): manipulating the fields themselves or polynomials over We can also work on it in more piecemeal fashion tool, but hopefully a fix for one will fix the others. At the very least, we can push linear algebra things up to the generic implementation and it really should work there. |
I agree, that it's a hack rather than a fix. For this PR, I think we should keep the code written as is for future-proofing when the other implementations will work. I will leave it up to you what kind of doctests you want for the other implementations. |
|
"The good news is that it raises an error or crashes" — that's the good news. Fun fact: it seems that matrix-vector multiplication with entries in My preference is to not add any doctests for the alternate implementations. Those implementations for Oh, I just found out that the old stuff doesn't work for all simplicial sets, just for some. Simplicial sets can be somewhat sparser than simplicial complexes, and as a result, the boundary maps in the chain complexes can be zero. I happened to have only tested simplicial sets like that, and when the boundary maps are zero, the algorithm skips the matrix multiplication altogether. I just tried a case with a nontrivial boundary map, and it hits the same problem with matrix multiplication. So even more reason to not include doctests. I am a little concerned that if we add doctests for In summary: the doctests here wouldn't test anything beyond certain linear algebra computations, and those should be tested elsewhere. There should be nothing in this code that relies on a particular implementation of If you really want doctests, I would probably just want to put in failures marked with "# known bug". |
Great, and thank you for all of your feedback! |
jhpalmieri
force-pushed
the
cohomology-as-module
branch
from
c3e9844
to
4df0d1a
Compare
|
Documentation preview for this PR (built with commit 4df0d1a; changes) is ready! 🎉 |
…gebra
Mod 2 (co)homology as a module over the Steenrod algebra
<!-- ^^^^^
Please provide a concise, informative and self-explanatory title.
Don't put issue numbers in there, do this in the PR body below.
For example, instead of "Fixes sagemath#1234" use "Introduce new method to
calculate 1+1"
-->
<!-- Describe your changes here in detail -->
Implement:
- vector space duality for (co)homology of cell complexes with field
coefficients, switching between homology and cohomology
- Steenrod operations on homology and cohomology, acting from the left
and from the right
The Steenrod operation "Sq(i)" was already implemented for cohomology
rings, raising an error if it was used with a base field other than
GF(2). Now there is a new class, `CohomologyRing_mod2`, which should
only be used with that base field, and the `Sq` method is attached to
Elements of that new class.
Using Steenrod operations is more transparent: in addition to doing
`x.Sq(i)`, users can do `Sq(i) * x` or `x * Sq(i)`, or indeed `a * x` or
`x * a` for any element `a` of `SteenrodAlgebra(2)`. (The elements
`Sq(i)` generate the Steenrod algebra, but they do not constitute a full
list of the elements.)
This fixes sagemath#6103.
<!-- Why is this change required? What problem does it solve? -->
<!-- If this PR resolves an open issue, please link to it here. For
example "Fixes sagemath#12345". -->
<!-- If your change requires a documentation PR, please link it
appropriately. -->
### 📝 Checklist
<!-- Put an `x` in all the boxes that apply. -->
<!-- If your change requires a documentation PR, please link it
appropriately -->
<!-- If you're unsure about any of these, don't hesitate to ask. We're
here to help! -->
<!-- Feel free to remove irrelevant items. -->
- [X] The title is concise, informative, and self-explanatory.
- [X] The description explains in detail what this PR is about.
- [X] I have linked a relevant issue or discussion.
- [X] I have created tests covering the changes.
- [X] I have updated the documentation accordingly.
### ⌛ Dependencies
<!-- List all open PRs that this PR logically depends on
- sagemath#12345: short description why this is a dependency
- sagemath#34567: ...
-->
<!-- If you're unsure about any of these, don't hesitate to ask. We're
here to help! -->
URL: sagemath#36310
Reported by: John H. Palmieri
Reviewer(s): John H. Palmieri, Travis Scrimshaw
Mod 2 (co)homology as a module over the Steenrod algebra
Implement:
The Steenrod operation "Sq(i)" was already implemented for cohomology rings, raising an error if it was used with a base field other than GF(2). Now there is a new class,
CohomologyRing_mod2, which should only be used with that base field, and theSqmethod is attached to Elements of that new class.Using Steenrod operations is more transparent: in addition to doing
x.Sq(i), users can doSq(i) * xorx * Sq(i), or indeeda * xorx * afor any elementaofSteenrodAlgebra(2). (The elementsSq(i)generate the Steenrod algebra, but they do not constitute a full list of the elements.)This fixes #6103.
📝 Checklist
⌛ Dependencies