Macaulay2 / Macaulay2/M2

freeResolution over a polynomial ring returns the given presentation as dd_1, so the zero module gets a length-2 resolution

Open
#4,608 0 comments 0 reactions 0 assignees View on GitHub
bugs directory Core
Dominant language
Macaulay2
Stars
435
Forks
297
Avg merge
4d 20h
Merged PRs (30d)
11

Description

This issue was triaged from [`bugs/dan/2-res-ZZ`](https://github.com/Macaulay2/M2/blob/388c1ff0ce30d83751dea7bc7eac77fdc1305dd7/bugs/dan/2-res-ZZ), one of the 857 files removed from the pre-GitHub `bugs/` tree by [`d2c8d27826`](https://github.com/Macaulay2/M2/commit/d2c8d27826) and catalogued in [#36](https://github.com/Macaulay2/M2/issues/36). **The commentary below was written by Claude (Claude Opus 5, via Claude Code)**, not by @d-torrance, whose account posted it -- please weigh it accordingly.

The original file, verbatim (137 lines)

```text
-*-M2-*-

Date: Mon, 10 Jul 2006 17:00:58 -0500 (CDT)
From: Dan Grayson
To: Michael Stillman
CC: dan@math.uiuc.edu
In-reply-to: <7B0684EC-05B6-4481-93BC-C940CEA1B8C3@math.cornell.edu> (message
from Michael Stillman on Mon, 10 Jul 2006 17:05:55 -0400)
Subject: Re:
Reply-to: dan@math.uiuc.edu

That's pretty dramatic, but there can't really be a difference between Up and
Down, right??

Below are two examples where the complex is one step too long, and "res"
doesn't notice and doesn't keep going. Well, until a few days ago, this was a
problem even for ZZ, because we weren't getting a basis of the kernel.

I have to :

(1) make res keep going past the gdim of the ring if necessary (now!)

(2) find out why res plugged in the presentation matrix as dd_1 in the
first example below and make it do better

We have to :

(3) work on making res over ZZ[x1,...,xn] stop at the gdim.

=============================================================================

i34 : R = ZZ[]

o34 = R

o34 : PolynomialRing

i37 : res coker random(R^6,R^9)

6 9 3
o37 = R <-- R <-- R

0 1 2

o37 : ChainComplex

i38 : oo.dd

6 9
o38 = 0 : R <----------------------------------- R : 1
| 1 3 -2 -8 -7 -10 -6 1 -2 |
| 8 9 -3 3 -4 4 8 -3 -3 |
| -4 0 -6 8 1 4 2 5 0 |
| -1 -6 5 -5 -2 4 -5 7 5 |
| -5 -2 -7 -2 1 -9 -7 -4 4 |
| 4 -5 -1 -9 7 -5 5 -7 -5 |

9 3
1 : R <------------------------------------ R : 2
| 218521800 35686471 -254225 |
| -238647554 -38973175 277639 |
| 20628596 3368825 -23999 |
| 209385531 34194439 -243596 |
| -113587500 -18549803 132146 |
| -136132056 -22231523 158374 |
| -9554874 -1560394 11116 |
| 0 1 0 |
| 1 0 0 |

o38 : ChainComplexMap

=============================================================================

ii32 : (R = ZZ[x,y, MonomialOrder=>Position=>Up];f = substitute(f,R);C = res coker f;C.dd)

2 4
oo32 = 0 : R <----------------------------------------------------------- R : 1
| 5x2-4xy+4y2 -10x2+4xy+4y2 -7x2+9xy-3y2 -3x2+4xy+5y2 |
| 9xy-8y2 5x2+3xy+2y2 -8x2-5xy x2+7xy-9y2 |

4
1 : R <------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
{2} | -136722511x2+508295663xy+2754766723y2 54580868x2-202917193xy-1099730831y2 -53212908692302306300064255940754289439744739856558x3-53086405710813341581155875801904160474
{2} | -47555656x2+197788612xy+1016157229y2 18984643x2-78959370xy-405660278y2 -18508837806018193495674523805479752848606866037065x3-15322358002348073349940782215427602127
{2} | -29722285x2-1744716xy+1323117246y2 11865405x2+696313xy-528201832y2 -11568023628761370934796577378424845530379291273165x3-15534005920279651875133226234531046777
{2} | 221657354xy-2222868814y2 25x2-88487537xy+887391788y2 5x3+28688253xy2-20029355974091893607911083423758887086505526558973102y3

3
2 : R <------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
{4} | -69408141772568225608779464270549073182275761877476x+245669524475381867896103376635820012945335478651190786374y -11568023628761370934796577378424845530379293646246x2+
{4} | -35666742x+615393002054573706916683808789897907549424076801329998562y -5944457x2+1025655003424289511527806347983163179249040
{5} | 178333710 29722285x

2 1
3 : R <-------------- R : 4
{5} | -x |
{6} | 6 |
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
3
------------------------------------------------------------------------------------------------------------------------------------ R : 2
9954265867492x2y+7053909704654469937493178585167122023668871442988555xy2+24822345954938415555474511615716373813559380092292122y3 |
2240696008375x2y+2691681438418724338191708775736050090284051319342618xy2+9157281936340140986298171055950503364962650853789529y3 |
6603785062029x2y+1173293228498792925665264737710959386694713657082153xy2+11923910564884919375845104522624357760520163663153698y3 |
|

2
-------------------------------------------------------------- R : 3
40944920745896977982683896105970002157555913108531797729xy |
12800221666427xy |
|

oo32 : ChainComplexMap

> To: Dan Grayson
> From: Michael Stillman
> Subject:
> Date: Mon, 10 Jul 2006 17:05:55 -0400
>
> Try this out, over and over:
>
> R = ZZ[x,y]
> f = random(R^2,R^{4:-2})
> C = res coker f
>
> R = ZZ[x,y, MonomialOrder=>Position=>Down]
> f = substitute(f,R)
> C = res coker f
>
> R = ZZ[x,y, MonomialOrder=>Position=>Up]
> f = substitute(f,R)
> C = res coker f
>
> I get that 'Down' is often the worst...
>
```

### Where it stands today

Over a polynomial ring, `freeResolution` hands the given presentation matrix back as `dd_1` without
minimizing it, so a module that is zero can get a free resolution of length 2.

The 2006 file below asks, as its second numbered task, "find out why res plugged in the presentation
matrix as `dd_1` in the first example and make it do better". Running its own example:

```m2
i1 : R = ZZ[];

i2 : f = random(R^6, R^9);

i3 : C = freeResolution coker f;

i4 : apply(toList(0..length C), i -> rank C_i)

o4 = {6, 9, 3}

i5 : C.dd_1 == f

o5 = true
```

`coker f` is the **zero module** — the Smith normal form of `f` is six units, and
`minimalPresentation` agrees, giving a 0×0 presentation. So that is a length-2 free resolution of 0,
whose first differential is the input.

### It is not about `ZZ`

`ZZ` is the one ring where this comes out right, which is what makes it easy to misread. The same
zero module over four rings:

```m2
ZZ : freeResolution coker id_(ZZ^3) -> {0}
ZZ[] : freeResolution coker id_(R^3) -> {3, 3}
ZZ[x] : freeResolution coker id_(R^3) -> {3, 3}
QQ[x] : freeResolution coker id_(R^3) -> {3, 3}
```

`QQ[x]` behaves exactly like `ZZ[]`, so this is a polynomial-ring issue, not a `ZZ` one.

### Why `ZZ` is different

`resolutionOverZZ` is the only strategy that prunes — it computes `minimalPresentation M` — and it
declines on anything that is not literally `ZZ`:

https://github.com/Macaulay2/M2/blob/development/M2/Macaulay2/packages/Complexes/FreeResolution.m2#L417-L419

`ZZ[]` is not `ZZ`, so the hook returns `null` and `Strategy => 1`, the engine resolution, answers
instead. Confirmed by reading `M.cache.ResolutionObject.Strategy` after the call: `null` over `ZZ`,
`1` over `ZZ[]`.

The commented-out LLL hook a few lines below carries the same top-of-the-tower guard,
`if ring M === ZZ then ...`, and already cites #3785 next to it.

### `minimalBetti` inherits it

```m2
i1 : S = QQ[x,y];

i2 : m = matrix{{1_S, x}}; -- homogeneous; coker m is the zero module

i3 : minimalBetti coker m

o3 = BettiTally{(0, {0}, 0) => 1, (1, {0}, 0) => 1}
```

`minimize` applied to the same complex does give `{0}`, so the machinery to cancel the unit entry
exists and is simply not reached.

### Relation to existing issues

#3785's own example (`res coker id_(ZZ^3)`) passes today, because `res` is now `freeResolution` and
`ZZ` takes the pruning hook. Its question — what the answer should be — is unresolved for every
other ring. #3802 collects the surrounding `LLLBases` problems, but the hook at issue here is in
`Complexes`, and the LLL one is commented out.

The file's other two tasks are met: (1) resolutions do continue past the global dimension when
needed — over `ZZ[]`, gdim 1, the example above has length 2 — and (3) over `ZZ[x,y]` they stop at
length 3, which is the global dimension.

`open` · disposition `issue` · source of truth: [`bug-triage/catalog.tsv`](https://github.com/d-torrance/M2/blob/bug-triage/bug-triage/catalog.tsv)

Contributor guide

No contributing guide indexed for this repository

Research direction

Start in M2/Macaulay2/packages/Complexes/FreeResolution.m2 around the resolution strategy hook at lines 417–419, then run the issue's reproducer over ZZ[], ZZ[x], and QQ[x]. Done means freeResolution coker id_(R^3) no longer retains the input presentation as dd_1 and produces the expected zero-module resolution.

Written by the indexing model from the issue text.

Assessment

Domain
tooling
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
52/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.