Complexes, OldChainComplexes, and HomologicalAlgebraPackage

[mahrud]

The major changes here include:

• Created OldChainComplexes package to preserve old functionality. All homological algebra routines from Core are moved there along with the majority of their documentation. A handful (e.g. Ext, Tor, pdim, regularity) are still documented in Macaulay2Doc.
• Moved where Core becomes a package to Core.m2. This is mostly a superficial change, but I think it fits a lot better and for instance makes it easier to find the package info or preloaded package list in Core.m2 rather than middle of packages.m2!
• res/resolution are now symbols that are overwritten whenever one of Complexes or OldChainComplexes are loaded. The caveat is that one of them doesn't allow the option FastNonminimal, so we should add Options => true at some point.
• Added HomologicalAlgebraPackage for choosing which of Complexes or OldChainComplexes to load.
• I changed resolution(Complex) to freeResolution(Complex) to avoid having Complexes depend on OldChainComplexes. I believe Mike and Greg were okay with this.
• the Complex <--> ChainComplex conversion code is now loaded by the package that is loaded last, whichever it is. This means there may be some weird consequences, but it should be fine ...

Things that may need to be changed later:

• I added formation(Complex) for a test to pass, but it needs to bed documented, and formation(ComplexMap) probably also needs to be added
• I added GradedModule as a synonym of Complex for a few packages which only needed this symbol as the output of HH, for instance. A better solution might be to create a new GradedModule type in Complexes and overwrite the other symbol, then the documentation would reflect this as well.
• I added LLL as a strategy for free resolutions over ZZ, but it seems like this changed the result, since OverZZ already existed, and changed the documentation node Strategy for free resolutions over the integers. I will comment this out for now, but should this also be changed in OldChainComplexes? What was the point of the LLL strategy to begin with? c.f. Free resolutions over ZZ using LLL #3785.
• [betti, Minimize] doesn't do anything, nor is it documented in Complexes. Should it be? Same with [extend, Verify]

[mahrud]

@mikestillman I think this is ready.

[mahrud]

I compared the entire html documentation before and after this change, and feel pretty confident that we didn't miss anything major. Do we think this can make it into this release?

It should hopefully not change anything by default, but provide the option of testing the complete switch to Complexes by setting a variable in init.m2.

Since the tests passed already, I'll wait to see if you have anything else that needs changed before I fix the conflicts.

[mikestillman]

@mikestillman I think this is ready.

Taking a look!

[mikestillman]

@mahrud Where is the list of preloaded packages? I can't seem to find it...

edit: found it, it is in m2/packages.m2. My problem: I was searching for ChainComplexes, Complexes and finding no occurrence in m2 directory. Where is OldChainComplexes installed as a preloaded package?

edit: aargghhh... on wrong branch... Found it all... (in Core.m2). Sorry for the spam...

[mikestillman]

@mahrud Maybe we should have HomologicalAlgebraPackage be checked that it is either "OldChainComplexes" or "Complexes"? Or if it is neither, give a warning and choose one?

[mahrud]

Maybe we should have HomologicalAlgebraPackage be checked that it is either "OldChainComplexes" or "Complexes"? Or if it is neither, give a warning and choose one?

If it is not a valid package name, they still get an error that the package doesn't exist, right?

[mahrud]

Where is the list of preloaded packages? I can't seem to find it...

This is exactly why I moved it to Core.m2 XD I always had to grep for "preloaded packages".

[mikestillman]

@mahrud So far, most everything is looking good. There are a few small issues so far. In trying to get Complexes to be preloaded, and not OldChainComplexes, I hit the following issues (I might edit this list later).

• koszul isn't defined in Complexes. But it is easy to do so, adding one line to Complexes/ChainComplex.m2 (edit: actually, it might be better for koszul to not be defined in Complexes. (i.e. for OldChainComplexes preloaded, this gives a Complex rather than a ChainComplex in e.g. Spectral sequences...))
• a test in programming with threads asks for whether the task result is of class ChainComplex, this fails if ChainComplex is not a type. Instead, I change the test to test whether the length of the resolution is 3.
• here is a curious one, that I am trying to understand: MultiplicitySequence. It gets a number of errors, as well as multiple (I mean, alot of) redefined warnings, and the examples also give errors. (edit: MultiplicitySequence uses OldPolyhedra, in particular the function intersection(4 matrices), which returns an OldPolyhedra Polyhedron. But for some reason, all other functions, e.g. vertices, are with Polyhedra. So we get a mismatch. But it doesn't seem to be a problem in 1.24.11? I'm not sure I understand the issue yet, but it keeps the build with Complexes preloaded from completing)

I am looking into the last one. Should I commit the first two (edit: only the second) small changes, and push to your branch?

I didn't try to fix the conflicts with development, I was just testing the branch on its own.

[mikestillman]

@mahrud I have a few things I want to check, but this is basically good. Please continue with resolving the conflicts. Yes, I would really like this to be in the upcoming release if possible.

(edit: I did not yet add any commits to the branch)

[mahrud]

• koszul isn't defined in Complexes. But it is easy to do so, adding one line to Complexes/ChainComplex.m2 (edit: actually, it might be better for koszul to not be defined in Complexes. (i.e. for OldChainComplexes preloaded, this gives a Complex rather than a ChainComplex in e.g. Spectral sequences...))

Exactly, I had a commit where I changed koszul to return a Complex, and a bunch of things failed (probably fixable, but felt unnecessary given that koszulComplex exists).

• a test in programming with threads asks for whether the task result is of class ChainComplex, this fails if ChainComplex is not a type. Instead, I change the test to test whether the length of the resolution is 3.

Sure, alternatively we could replace it with a grobner basis or something.

• here is a curious one, that I am trying to understand: MultiplicitySequence. It gets a number of errors, as well as multiple (I mean, alot of) redefined warnings, and the examples also give errors. (edit: MultiplicitySequence uses OldPolyhedra, in particular the function intersection(4 matrices), which returns an OldPolyhedra Polyhedron. But for some reason, all other functions, e.g. vertices, are with Polyhedra. So we get a mismatch. But it doesn't seem to be a problem in 1.24.11? I'm not sure I understand the issue yet, but it keeps the build with Complexes preloaded from completing)

The simple fix is mahrud@65a7209. I have a branch here where I made Complexes the default homological algebra package and fixed all three of these, but I think for this release it's fine. I will include the fix for the third one in this PR though.

[mahrud]

@mikestillman @d-torrance is this good to merge?

[mikestillman]

Greg and I have reviewed most of the changes, and this looks good.

As long as the googletest submodule issue has been fixed, this looks good to be merged!