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

[sagetrac-git]

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

8bcdfdf

Trac #31669: minor typos

[sagetrac-git]

Changed commit from 0393c25 to 8bcdfdf

[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?

[sagetrac-git]

Changed commit from 8bcdfdf to 718d354

[sagetrac-git]

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.

[sagetrac-git]

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

98e3ed6

Trac #31669: add differentials to category

[sagetrac-git]

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?

[sagetrac-git]

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

ffc848a

Trac #31669: small documentation fix of #31691

[sagetrac-git]

Changed commit from 969d9e3 to ffc848a

[mjungmath]

comment:43

Ready for review. Patchbot is 'green'.

[tscrim]

comment:44

Replying to @mjungmath:

But it seems like this is done all over Sage:

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

Yes, that is what I was referring too. However, just because it is used many places elsewhere doesn't mean you shouldn't use it. That is typically older code and is a weaker test. Someone could pass a weaker category than the code actually needs, which would be a problem.

[mjungmath]

comment:45

I don't know whether is_subcategory is the state of the art here. Sometimes, categories are not compatible with each other. Or a subcategory (in the mathematical sense) is not recognized as such. I have a bad feeling that this can lead to undesired results.

[tscrim]

comment:46

This is what we want to use. Please make the change to use it. If categories are incompatible, then there is a bigger issue that this will alert you to.

[mjungmath]

comment:47

I still don't think this is what we should use. For example, assume that the class represents an object in the category of groups. Now I want to inherit from this class and turn it into a ring. Passing Rings() to the initialization would then cause an error:

sage: Groups().or_subcategory(Rings())
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-2-38547a21b34f> in <module>
----> 1 Groups().or_subcategory(Rings())

/ext/sage/sage-9.2/local/lib/python3.8/site-packages/sage/categories/category.py in or_subcategory(self, category, join)
   1876         else:
   1877             if not category.is_subcategory(self):
-> 1878                 raise ValueError("Subcategory of `{}` required; got `{}`".format(self, category))
   1879             return category
   1880 
ValueError: Subcategory of `Category of groups` required; got `Category of rings

Even with join=True we get an undesired result:

sage: Groups().or_subcategory(Rings(), join=True)
Category of inverse rings

What we really want to do is overwrite the category in that case.

[tscrim]

Reviewer: Travis Scrimshaw

[tscrim]

comment:48

That error is telling you that you are doing something mathematically nonsensical. A ring is not a (multiplicative) group because it doesn't have inverses. Thus, your example gives even more reason you want to use it.

[mjungmath]

comment:49

Right, Sage distinguishes between multiplicative and additive groups. Probably a bad example. The same error would occur for additive groups though, except that join=True gives what we want. But I am not sure whether we always want to join categories and never make it possible to overwrite them for inheritance purposes.

I am sure you can somehow construct another example that leads to something undesirable. Besides, there must be a reason why or_subcategory is literally never used for that purpose.

I'd appreciate an additional opinion here. Matthias?

[jhpalmieri]

comment:50

I don't have an opinion about this particular situation, but in my experience, Travis knows the category code well, and I try to follow his advice.

[tscrim]

comment:51

Replying to @mjungmath:

Right, Sage distinguishes between multiplicative and additive groups. Probably a bad example. The same error would occur for additive groups though, except that join=True gives what we want.

It does not result in an error:

sage: from sage.categories.additive_groups import AdditiveGroups
sage: AdditiveGroups().or_subcategory(Rings())
Category of rings

But I am not sure whether we always want to join categories and never make it possible to overwrite them for inheritance purposes.

I don't understand. Join categories are used all over the place in Sage. When creating a new category, we often (maybe even typically) build it as a join or a subcategory thereof.

I am sure you can somehow construct another example that leads to something undesirable.

If you do, then you are exposing a bug in the category hierarchy.

Besides, there must be a reason why or_subcategory is literally never used for that purpose.

This is used in many places in Sage:

uqtscrim@SMP-36PQ8T2:~/sage/src/sage$ grep -R -l "or_subcategory" *
algebras/lie_algebras/quotient.py
algebras/lie_algebras/nilpotent_lie_algebra.py
algebras/lie_algebras/structure_coefficients.py
algebras/lie_algebras/lie_algebra.py
algebras/lie_algebras/subalgebra.py
algebras/lie_algebras/abelian.py
algebras/tensor_algebra.py
algebras/lie_conformal_algebras/lie_conformal_algebra_with_basis.py
algebras/lie_conformal_algebras/graded_lie_conformal_algebra.py
algebras/lie_conformal_algebras/finitely_freely_generated_lca.py
algebras/lie_conformal_algebras/lie_conformal_algebra_with_structure_coefs.py
algebras/clifford_algebra.py
algebras/associated_graded.py
algebras/finite_dimensional_algebras/finite_dimensional_algebra.py
categories/examples/semigroups.py
categories/coxeter_groups.py
categories/category.py
combinat/free_module.py
combinat/diagram_algebras.py
combinat/posets/posets.py
combinat/crystals/subcrystal.py
combinat/crystals/virtual_crystal.py
combinat/combinat.py
groups/lie_gps/nilpotent_lie_group.py
groups/perm_gps/permgroup.py
groups/indexed_free_group.py
homology/simplicial_complex.py
homology/homology_vector_space_with_basis.py
manifolds/manifold.py
modules/with_basis/subquotient.py
modules/with_basis/morphism.py
monoids/indexed_free_monoid.py
rings/function_field/order.py
rings/function_field/valuation_ring.py
rings/function_field/differential.py
rings/function_field/function_field.py
rings/lazy_laurent_series_ring.py
rings/polynomial/ore_polynomial_ring.py
rings/polynomial/ore_function_field.py
rings/polynomial/polynomial_quotient_ring.py
rings/asymptotic/asymptotics_multivariate_generating_functions.py
sets/finite_set_maps.py
sets/recursively_enumerated_set.pyx
sets/non_negative_integers.py
tensor/modules/finite_rank_free_module.py

One of the most notable is in combinat/free_module.py, which is the base class of many algebras in Sage.

[mjungmath]

comment:52

Replying to @tscrim:

Replying to @mjungmath:

Right, Sage distinguishes between multiplicative and additive groups. Probably a bad example. The same error would occur for additive groups though, except that join=True gives what we want.

It does not result in an error:

sage: from sage.categories.additive_groups import AdditiveGroups
sage: AdditiveGroups().or_subcategory(Rings())
Category of rings

Mh, you are right, it works. But according to the documentation this input should be invalid, too:

or_subcategory(category=None, join=False)
Return category or self if category is None.

INPUT:

    category – a sub category of self, tuple/list thereof, or None

    join – a boolean (default: False)

In that case, the documentation should be revised.

[mjungmath]

comment:55

I think the documentation of or_subcategory should be modified accordingly, at least the INPUT part.

[mjungmath]

comment:56

I apologize for my stubbornness. :D

[sagetrac-git]

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

4bceb9b

Trac #31669: use or_subcategory

[sagetrac-git]

Changed commit from ffc848a to 4bceb9b

[mjungmath]

comment:58

Here we go, and thank you for your patience, Travis!

[tscrim]

comment:60

LGTM. Thank you.

[mjungmath]

comment:61

Thank you for the review! :)

[vbraun]

Changed branch from u/gh-mjungmath/category_of_chain_complexes___co_homology_functor to 4bceb9b