Category of chain complexes: (co)homology functor

[mjungmath]

In this ticket, we equip the category of chain complexes with a method homology yielding the associated homology. The corresponding homology functor will use this method.

This happens in view of Čech cohomology, Morse homology and de Rham cohomology on manifolds.

Comments and opinions are as always welcome.

Depends on #31691

CC: @mkoeppe @tscrim @egourgoulhon @jhpalmieri

Component: categories

Keywords: homology

Author: Michael Jung

Branch/Commit: 4bceb9b

Reviewer: Travis Scrimshaw

Issue created by migration from https://trac.sagemath.org/ticket/31669

[mjungmath]

Branch: u/gh-mjungmath/category_of_chain_complexes___co_homology_functor

[mjungmath]

comment:3

First draft. Comments are welcome.

---

New commits:

bcdee3a	Trac #31669: add cochains and (co)homology method
0393c25	Trac #31669: (co)homology functor added

[mjungmath]

Commit: 0393c25

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

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

8bcdfdf

Trac #31669: minor typos

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from 0393c25 to 8bcdfdf

[mjungmath]

Description changed:

--- 
+++ 
@@ -1,4 +1,4 @@
-In this ticket, we equip the category of chain complexes with a method `homology` yielding the associated homology. The corresponding homology functor will use this method. We furthermore establish a new category of cochain complexes.
+In this ticket, we equip the category of chain complexes with a method `homology` yielding the associated homology. The corresponding homology functor will use this method.

 This happens in view of Čech cohomology, Morse homology and de Rham cohomology on manifolds.

[mjungmath]

Changed keywords from homology, cohomology to homology

[mjungmath]

Author: Michael Jung

[mjungmath]

comment:5

chain_complex doesn't make a distinction between chain and cochain complexes. Probably because it also allows multigrading.

Should we remove the category of cochain complexes then? I mean, in a broad sense, cochain complexes can be seen as generalized chain complexes, no?

Btw, is it customary to add a mathematical description in the category section?

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from 8bcdfdf to 718d354

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

6988be0	Trac #31669: homology functor
718d354	Trac #31669: add category of chain complexes to commutative_dga

[mjungmath]

comment:7

Here is a proposal without cochain complexes.

---

New commits:

6988be0	Trac #31669: homology functor
718d354	Trac #31669: add category of chain complexes to commutative_dga

[tscrim]

comment:9

There is no difference as the degree of the chain map is part of the data of a chain complex. I agree that it is good to not have a category of cochain complexes.

You can add a very brief description to the category, but nobody really reads that part IMO.

[mjungmath]

comment:10

I have added a differential method to the category since this is a crucial ingredient for chain complexes. For consistency it might also be a good idea to turn differentials of chain_complex into morphisms in the category of modules like it is done in commutative_dga.

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

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

98e3ed6

Trac #31669: add differentials to category

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from 718d354 to 98e3ed6

[mjungmath]

comment:12

If there is nothing you'd like to add, that should be it. I added the above task as a TODO comment. Perhaps I even open a ticket.

[tscrim]

comment:14

Rather than raise a NotImplementedError, it is better if you mark them as @abstract_method.

_apply_functor_to_morphism is missing doctests.

I would not change the title doc of chain_complex.py. It is possible that non-bounded chain complexes are added to that file eventually.

Should we allow HomologyFunctor to have a default of n=None so it returns the entire homology?

This is a more of a question for John. When I think of cohomology, I think there should be some extra ring structure. If the degree of the differential is negative, can we generally assume there is a ring structure on the homology or is this something special based on the construction?

[mjungmath]

comment:15

Replying to @tscrim:

Rather than raise a NotImplementedError, it is better if you mark them as @abstract_method.

_apply_functor_to_morphism is missing doctests.

That is because we don't have any examples to apply here, or do we?

I would not change the title doc of chain_complex.py. It is possible that non-bounded chain complexes are added to that file eventually.

Well, that can be done if that finally happens, no?

Should we allow HomologyFunctor to have a default of n=None so it returns the entire homology?

This is a more of a question for John. When I think of cohomology, I think there should be some extra ring structure. If the degree of the differential is negative, can we generally assume there is a ring structure on the homology or is this something special based on the construction?

I agree, it should, and I will add it accordingly. For the moment however, neither chain_complex nor commutative_dga provide (co)homology in terms of a graded ring.

[mjungmath]

comment:16

Replying to @mjungmath:

Replying to @tscrim:

Rather than raise a NotImplementedError, it is better if you mark them as @abstract_method.

_apply_functor_to_morphism is missing doctests.

That is because we don't have any examples to apply here, or do we?

Perhaps I can add an example together with #31693.

[mjungmath]

comment:17

As for _apply_functor_to_morphism we could enforce a method homology_raw (cf. commutative_dga) which returns the homology as an actual quotient whose elements admit a lift method. Then the _apply_functor_to_morphism is rather generic:

Lift the homology element, apply the original morphism to it, reduce to the quotient.

At that end one could implement isomorphisms from the already lifted homology groups to the homology groups emerged as quotient.

Not sure whether this is a feasible approach. Travis, what do you think?

I would have wished that the homology already occurs as a quotient in the first place. Is there a reason why this hasn't been done so?

[jhpalmieri]

comment:19

Replying to @mjungmath:

I would have wished that the homology already occurs as a quotient in the first place. Is there a reason why this hasn't been done so?

It is much faster to compute the homology as an abstract group (by computing the Smith normal form of the boundary matrices) than to compute the cycles as a subgroup of the chains and then the homology as a quotient of the cycles.

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

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

6f00253

Trac 31669: lift and reduce to/from homology

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from 98e3ed6 to 6f00253

[mjungmath]

comment:21

Check out my new commit. This approach is a bit more generic. What do you think?

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

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

78475b6

Trac 31669: docstring improved

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from 6f00253 to 78475b6

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from 78475b6 to 41461f7

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

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

41461f7

Trac 31669: minor docstring improved

[tscrim]

comment:24

Even if we have no examples, it still needs a doctest (even if it just showing that it has not been defined).

Yes, we can change the title if that indeed happens, but right now, let's leave it alone.

I don't like the idea of enforcing a homology_raw. Implementors should be free to implement what works best for them and their problem at hand as per John's comment. Things at the category level should be kept as generic as possible.

It would be better to have this as a generic implementation in the category by using some assumption on the chain complex and the corresponding morphisms. Of course, it would need a better name and could be the generic implementation, but I am not sure we want to force an option that homology needs to be realized as a quotient.

[mjungmath]

comment:25

Replying to @tscrim:

Even if we have no examples, it still needs a doctest (even if it just showing that it has not been defined).

Yes, we can change the title if that indeed happens, but right now, let's leave it alone.

I don't like the idea of enforcing a homology_raw. Implementors should be free to implement what works best for them and their problem at hand as per John's comment. Things at the category level should be kept as generic as possible.

It would be better to have this as a generic implementation in the category by using some assumption on the chain complex and the corresponding morphisms. Of course, it would need a better name and could be the generic implementation, but I am not sure we want to force an option that homology needs to be realized as a quotient.

Have you checked my last commits? I already dropped most things you are referring to.

Instead of homology_raw, I have introduced two methods: lift_from_homology and reduce_to_homology which lifts an homology class to a representative and reduces a cycle to its homology class respectively. These can be overwritten depending on the implementation.

As for renaming: I really don't care. I just think that it is way smoother if the title fits the content. What I meant: you can change it back as soon as the implementation has been generalized, at which point the documentation needs to be refactored anyway.

[tscrim]

comment:26

Replying to @mjungmath:

Replying to @tscrim:

Even if we have no examples, it still needs a doctest (even if it just showing that it has not been defined).

Yes, we can change the title if that indeed happens, but right now, let's leave it alone.

I don't like the idea of enforcing a homology_raw. Implementors should be free to implement what works best for them and their problem at hand as per John's comment. Things at the category level should be kept as generic as possible.

It would be better to have this as a generic implementation in the category by using some assumption on the chain complex and the corresponding morphisms. Of course, it would need a better name and could be the generic implementation, but I am not sure we want to force an option that homology needs to be realized as a quotient.

Have you checked my last commits? I already dropped most things you are referring to.

Instead of homology_raw, I have introduced two methods: lift_from_homology and reduce_to_homology which lifts an homology class to a representative and reduces a cycle to its homology class respectively. These can be overwritten depending on the implementation.

Okay, I understand what you are trying to do. I didn't realize you were changing your approach with your last commit. It might be a slight abuse to have a functor for all n, but I think it should be fine.

As for renaming: I really don't care. I just think that it is way smoother if the title fits the content. What I meant: you can change it back as soon as the implementation has been generalized, at which point the documentation needs to be refactored anyway.

I am still a -1 on changing the title docstring of chain_complex.py. That file is for chain complexes. Just because we happen to have only bounded ones implemented doesn't mean we need to limit it right now.

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from 41461f7 to 57ee0af

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

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

57ee0af

Trac #31669: correct morphism

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

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

a475f2a

Trac #31669: make lift_from_homology entirely abstract

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from 57ee0af to a475f2a

[mjungmath]

comment:29

When #31691 has a positive review, I will add some examples for de Rham cohomology here.

[jhpalmieri]

comment:30

Replying to @tscrim:

Replying to @mjungmath:

As for renaming: I really don't care. I just think that it is way smoother if the title fits the content. What I meant: you can change it back as soon as the implementation has been generalized, at which point the documentation needs to be refactored anyway.

I am still a -1 on changing the title docstring of chain_complex.py. That file is for chain complexes. Just because we happen to have only bounded ones implemented doesn't mean we need to limit it right now.

Regarding this, I don't know much about kenzo, but it is conceivable that it handles unbounded chain complexes, and I think we should leave the title of Sage's chain complex module as is, in case the Sage-kenzo interface develops further and we can directly access its chain complexes. (Kenzo certainly handles topological spaces which have nonzero homology in infinitely many dimensions, but I don't know the details of how it handles the associated chain complexes.)

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

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

4746ddb	Trac #31691: turn mixed form algebra into de rham complex
fb8331a	Trac #31691: fix doctest in manifold.py
566176a	Trac #31691: new file + improved doc + cup product delegates to *
b2e40f9	Trac #31669: Merge branch 't/31691/public/31691_de_rham_complex' into t/31669/category_of_chain_complexes___co_homology_functor
c66dd12	Merge branch 'u/gh-mjungmath/category_of_chain_complexes___co_homology_functor' of trac.sagemath.org:sage into t/31669/category_of_chain_complexes___co_homology_functor
4cd7c03	Trac #31669: add examples

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from a475f2a to 4cd7c03

[mjungmath]

comment:33

Ready for review.

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from 4cd7c03 to 0308736

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

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

0308736

Trac #31669: minor doctest improvements

[jhpalmieri]

comment:35

Is #31691 a dependency of this ticket?

[tscrim]

Dependencies: #31691

[tscrim]

comment:36

Yes, I think it is.

Some comments:

Doctest failure:

sage -t --long --random-seed=0 src/sage/homology/hochschild_complex.py  # 1 doctest failed

I would use _n instead of __n as we don't need the name mangling.

A useful construction is Cat.or_subcategory(input_cat), which automatically returns Cat when input_cat=None.

[mjungmath]

comment:37

Replying to @tscrim:

Yes, I think it is.

Indeed. My mistake.

Some comments:

Doctest failure:

sage -t --long --random-seed=0 src/sage/homology/hochschild_complex.py  # 1 doctest failed

Saw it. I hope the Hochschild complex implementation provides a boundary map...

I would use _n instead of __n as we don't need the name mangling.

Check.

A useful construction is Cat.or_subcategory(input_cat), which automatically returns Cat when input_cat=None.

What do you propose?

[mjungmath]

comment:38

Replying to @tscrim:

A useful construction is Cat.or_subcategory(input_cat), which automatically returns Cat when input_cat=None.

Ah, you are probably referring to GCAlgebra. This or_subcategory seems also useful to improve the code for manifolds since this is similarly implemented as I did here.

[mjungmath]

comment:39

But it seems like this is done all over Sage:

def __init__(..., category=None):
    ...
    if category is None:
        category = SomeCategory()

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from 0308736 to 969d9e3