LengthLimit in Complexes

[mahrud]

I thought there was already an issue about this, but couldn't find it.

First problem:

needsPackage "Complexes"

R = QQ[x,y]/(x-y)
freeResolution R^1
-- error:
FreeResolutions.m2:147:17:(3):[16]: error: need to provide LengthLimit for free resolutions over quotients of polynomial rings

Which is bad because the input was free!

---

Second problem: let's say we already know that a module has finite projective dimension, just don't know what the number is (could be 5, could be 5 million). A reasonable idea would be to pass infinity and wait until M2 finds the projective dimension for you:

freeResolution(coker vars R, LengthLimit => infinity)
-- error
FreeResolutions.m2:147:17:(3):[16]: error: need to provide LengthLimit for free resolutions over quotients of polynomial rings

Which is both bad because the error is incorrect, that option is provided, and because it makes it impossible to compute projective dimension using the Complexes package.

---

More generally, a compiler shouldn't refuse to compile a program if it can't determine whether it will halt! Which is to say, in the case when the module does not have finite projective dimension, passing LengthLimit => infinity should run, but never finish. This is equivalent to something like:

m = presentation M
complex( {m} | while m != 0 list m = syz m )

which, should indeed be equivalent to while true do () if the resolution is infinite, and that is the intended outcome, not a bug.

cc: @ggsmith @mikestillman

[mahrud]

This is causing a lot of complications for me, especially with NormalToricVarieties now exporting Complexes by default. Do you have a plan for how to deal with this issue yet?

[mikestillman]

This is causing a lot of complications for me, especially with NormalToricVarieties now exporting Complexes by default. Do you have a plan for how to deal with this issue yet?

@mahrud I don't understand why this is causing alot of complications. Can you give an example that illustrates the problem?

[mikestillman]

Also, NormalToricVarieties imports Complexes but doesn't export Complexes.

[mahrud]

The minimal examples are the ones I provided above, but here are real world example:

1. I'm helping some people at MPI with working with certain combinatorial varieties that happen to be toric, but the particular presentation of the rings that we care about is not as polynomial rings, so we run into situations like:

needsPackage "MatrixSchubert"
S = quotient schubertDeterminantalIdeal {2,3,1} --- S is secretly a polynomial ring
freeResolution coker vars S -- fails

Here is what S looks like:

i5 :      describe S

     QQ[z   ..z   ]
         1,1   3,3
o5 = --------------
      (z   , z   )
        1,1   2,1

And of course freeResolution isn't called by us, it's called in places like (prune, CoherentSheaf).

2. Similarly, in the DbCY project from the Utah workshop, we had to resort to a kludge like this to get RHom to work on a tiny example: https://github.com/Macaulay2/M2/blob/5e978fab1b1c9238b3e33c4b892d9d83a88cb69e/M2/Macaulay2/packages/Varieties/SheafComplexes.m2#L12

[ggsmith]

The minimal examples are the ones I provided above, but here are real world example:

1. I'm helping some people at MPI with working with certain combinatorial varieties that happen to be toric, but the particular presentation of the rings that we care about is not as polynomial rings, so we run into situations like:

needsPackage "MatrixSchubert"
S = quotient schubertDeterminantalIdeal {2,3,1} --- S is secretly a polynomial ring
freeResolution coker vars S -- fails

Here is what S looks like:

i5 :      describe S

     QQ[z   ..z   ]
         1,1   3,3
o5 = --------------
      (z   , z   )
        1,1   2,1

And of course freeResolution isn't called by us, it's called in places like (prune, CoherentSheaf).

2. Similarly, in the DbCY project from the Utah workshop, we had to resort to a kludge like this to get RHom to work on a tiny example: https://github.com/Macaulay2/M2/blob/5e978fab1b1c9238b3e33c4b892d9d83a88cb69e/M2/Macaulay2/packages/Varieties/SheafComplexes.m2#L12

In the first case, aren't the quotient rings typically not polynomial rings. If so, then wouldn't one want to include a length limit. In other words, I don't see a "real" issue here.

In the second case, we need to ensure that the (prune, CoherentSheaf) code handles quotient rings (aka projective subvarieties) correctly. In particular, we need to insert the appropriate LengthLimits'' into the code in the Varieties'' package. Why isn't the issue exclusively in the Varieties package?

[mahrud]

In the first case, aren't the quotient rings typically not polynomial rings. If so, then wouldn't one want to include a length limit. In other words, I don't see a "real" issue here.

The modules we want to resolve always have finite free resolutions, either because the ring is isomorphic to a polynomial ring, or the variables in the module are disjoint from the variables in the quotient. This isn't rare at all.

In the second case, we need to ensure that the (prune, CoherentSheaf) code handles quotient rings (aka projective subvarieties) correctly. In particular, we need to insert the appropriate LengthLimits'' into the code in the Varieties'' package. Why isn't the issue exclusively in the Varieties package?

I don't understand this. The second case didn't have anything to do with prune.