Syncronize implementations of graded free resolutions of graded modules

[tscrim]

With #33275 (finitely presented graded modules of graded algebras) and #33950 (modules over polynomial rings), we now have two different implementations of graded free resolutions in Sage. However, their API and internal structures are very different. The goal of this ticket is primarily to start unifying the API.

My main proposal is to introduce a new method to finitely-presented graded modules called free_resolution() (or perhaps graded_resolution()) that creates an instance of a new class GradedFreeResolution (different from that on #33950). I see several advantages of doing this:

1 - It stores all of the computations. If you want a longer resolution, you do not need to compute the previous ones again.
2 - You no longer need to specify the length and all computations are done lazily when needed.
3 - You will then be able to manipulate the resolutions, such as being able to compute left derived functors.
4 - It would make it more consistent with #33950.

The reason I am suggesting calling it free_resolution() (or graded_resolution()) is so that we can go through a deprecation period for resolution() that just returns the maps. It would also make it consistent with #34379.

However, there are some questions about the API for both of these that we should try to make consistent:

I) What should __getitem__ return? On #33950 it returns the i-th module. This is what I would lean towards as the maps are a little more ambiguous.
II) Should this new class eventually be a subclass of FreeResolution_generic? Would it make sense for there be a common ABC at all?

Some other things to make consistent are:

• Being able to create submodules of graded free modules. This only works right now if we can echelonize the matrix. New classes might be needed.
• Being able to create a matrix from the free module morphisms. Although this is a general, mostly separate, issue as not every algebra implements an is_field() that is currently required for constructing a finite rank free module in the to_vector().
• The image() of a graded module morphism is not a (sub/quotient) module.

CC: @kwankyu @jhpalmieri @sverre320 @sagetrac-kvanwoerden @rrbruner @cnassau @louisng114 @trevorkarn

Component: algebra

Keywords: homology, resolutions

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

[tscrim]

comment:1

What are everyone's thoughts on this?

[kwankyu]

comment:2

For package structure, I suggest

(1) move the class sage.homology.free_resolution.FreeResolution_generic to sage.resolution.free_resolution.FreeResolution_generic

(2) move the class sage.homology.free_resolution.FreeResolution to sage.resolution.polynomial.free_resolution.FreeResolution

(3) move the class sage.homology.graded_resolution.GradedFreeResolution to sage.resolution.polynomial.graded_resolution.GradedFreeResolution

(4) create a new module sage.resolution.fp_graded.free_resolution for a new class GradedFreeResolution for fp graded modules, subclassed from sage.resolution.free_resolution.FreeResolution_generic

[kwankyu]

comment:3

What should __getitem__ return? On #33950 it returns the i-th module.

+1 to i-th module. For maps, we may use differential(i) or map(i) or d(i) (if you want the shortest)

Should this new class eventually be a subclass of FreeResolution_generic?

Yes.

[jhpalmieri]

comment:4

I'm not sure I agree that we need two directories homology and resolution: I think that the homology directory should handle things related to homological algebra. Or maybe I should phrase that as a question: what would go into resolution vs. homology vs. modules or other places? I also think that the mathematical notion of resolutions is more narrow and specialized than most of our other top-level Sage directories.

If we do want resolution, then I suppose it should instead be resolutions.

[kwankyu]

comment:5

Replying to @jhpalmieri:

I'm not sure I agree that we need two directories homology and resolution: I think that the homology directory should handle things related to homological algebra. Or maybe I should phrase that as a question: what would go into resolution vs. homology vs. modules or other places?

I agree that sage.homology.resolutions.(...) is logical. I worried that the full name for a free resolution class of, say, fp graded modules

sage.homology.resolutions.fp_graded.free_resolution.FreeResolution

is too long or too deep (just to me?). I have no strong opinion for this.

I also think that the mathematical notion of resolutions is more narrow and specialized than most of our other top-level Sage directories.

I agree.

[tscrim]

comment:6

I generally prefer avoid subdirectories until we have more than a small handful of files (maybe something around 4+) so there are not so many branches to go through. So I would have the following files in sage.homology:

• (keep) free_resolution.py
• (keep) graded_resolution.py
• new module fp_graded_resolution.py

Although it does get close to the point that it warrants a subdirectory. Admittedly this is mostly based on personal preference of not wanting to type a lot and the belief it is still easy enough to find the files. So it isn't a strong argument. Although, in part to comment:5, I am more opposed to having a sage.homology.resolutions.fp_graded subdirectory.

Side quip about overly specialized top-level directories: I think of lfunctions (and the finite Drinfeld modules ticket #33713 initially wanted a new top-level directory too, but I have convinced them out of it).

[kwankyu]

comment:7

Replying to @tscrim:

• (keep) free_resolution.py
• (keep) graded_resolution.py
• new module fp_graded_resolution.py

This is good too.

[kwankyu]

comment:8

Or free_resolution_fp_graded?

[kwankyu]

comment:9

John's preference would shadow mine.

[jhpalmieri]

comment:10

One problem is that there are lots of natural places for these files, since they deal with modules, homology, various types of algebras, and categories. So I think there may be no perfect solution. Keeping the main resolution files in homology makes as much sense as anything else. I would be tempted to name them

• resolution_free
• resolution_graded
• resolution_fp_graded

so that they are grouped together when you view the files alphabetically, but that's not a big deal.

Aside: I think that sandpiles should not be a top-level directory, either, or at least not until there are more than 2 files there.

[tscrim]

comment:11

Replying to @jhpalmieri:

One problem is that there are lots of natural places for these files, since they deal with modules, homology, various types of algebras, and categories. So I think there may be no perfect solution. Keeping the main resolution files in homology makes as much sense as anything else. I would be tempted to name them

• resolution_free
• resolution_graded
• resolution_fp_graded

so that they are grouped together when you view the files alphabetically, but that's not a big deal.

That's a good idea until there is a subdirectory (then they will just become free.py, etc.). There is some precedent for this too: see rings.real_* (in sage.matrix also, but it is redundant there).

Aside: I think that sandpiles should not be a top-level directory, either, or at least not until there are more than 2 files there.

+1 as they should either be in graphs or combinat IMO.

[dimpase]

Do we have a way to compute the Hilbert-Poincare series of f.g. subrings of polynomial rings? (at least, the graded case)

With finite free resolutions available, it's not too hard to implement, I think. @Bruno-TT