Odd behavior of gb / poincare

[pzinn]

Let's run the following program:

i1 : R=QQ[a..k]

o1 = R

o1 : PolynomialRing

i2 : I=trim ideal(a*b+c*d,a*e+b*f+c*g+d*h);

o2 : Ideal of R

i3 : M=cokernel gens I

o3 = cokernel | ae+bf+cg+dh ab+cd |

o3 : R-module, quotient of R^1

i4 : poincare M

o4 = 1 - 2T^2  + T^4

o4 : ZZ[T]

i5 : M.cache.poincare

o5 = 1 - 2T^2  + T^4

o5 : ZZ[T]

i6 : dim I

o6 = 9

Basically, I compute the poincare polynomial of some ideal. really internally that's the poincare polynomial of the module M which is the quotient module. and I check that M has correctly cached that poincare polynomial for future use. So far, so good. Now I restart M2 and do the following (slightly weird) thing:

i1 : R=QQ[a..k]

o1 = R

o1 : PolynomialRing

i2 : I=trim ideal(a*b+c*d,a*e+b*f+c*g+d*h);

o2 : Ideal of R

i3 : M=cokernel gens I

o3 = cokernel | ae+bf+cg+dh ab+cd |

o3 : R-module, quotient of R^1

i4 : use degreesRing R

o4 = ZZ[T]

o4 : PolynomialRing

i5 : M.cache.poincare=1-2*T^2+T^4;

i6 : dim I

o6 = 10

I just tried to be helpful and gave the poincare polynomial to M so M2 doesn't have to compute it. surprise: the dim of I (or M) comes out wrong. what happened? to see the problem let's check what the Groebner basis was. in the first case one gets

i8 : leadTerm gb presentation M

o8 = | ae ab cde |

which is fine, whereas in the second one gets

i6 : leadTerm gb presentation M

o6 = | ae ab |

which is incorrect. how did it get there? I'd have to go through the gb code and figure out how it uses the information on the poincare polynomial. but one thing is sure, something is fishy...

[pzinn]

I'd be happy to help, but it seems the computation of g.b. is done at a fairly low level, and I'd need some pointers on how the code is organized...

[mikestillman]

Sigh, the trim command seems to be double computing a minimal generating set, at least in the case when the argument is an Ideal. I wonder when this behavior started.

But for this issue, I think the problem is related to starting a GB without using Hilbert function information, and then continuing the GB computation using Hilbert function information. I'm not sure yet why that would matter, but I'll track it down.

Note that if one doesn't do the trim, it gives the correct answer:

i1 : R=QQ[a..k]

o1 = R

o1 : PolynomialRing

i2 : I=ideal(a*b+c*d,a*e+b*f+c*g+d*h);

o2 : Ideal of R

i3 : M=cokernel gens I

o3 = cokernel | ab+cd ae+bf+cg+dh |

                            1
o3 : R-module, quotient of R

i4 : use degreesRing R

o4 = ZZ[T]

o4 : PolynomialRing

i5 : M.cache.poincare=1-2*T^2+T^4;

i6 : assert(dim I == 9)

[pzinn]

for the record, I reported this bug because one of my programs actually produced a wrong result. I didn't just make up this example, it's the minimal version of the bug that occurred in my program. that's why I'd be glad if it was fixed. (for now I just disabled hilbert hints on my fork as a workaround)

[mikestillman]

@DanGrayson this would be a good one to fix for this release, I'm close to it. The problem is that it will be a (hopefully small) change to the state machine logic for GB's. So maybe it should wait until the next release. Thoughts?