bug in 'quotient()' over integers?

[jakobkroeker]

the following example fails (at least in M2 1.6)

R = ZZ[x,y,z]

I = ideal(17*x*z+10*x-43,41*x*y-16*x,47*z^2-2*z)
J = ideal( 34*x-16,-2*y*z,-20)

Q = quotient(J, I)
gQ = quotient(ideal gens gb J,ideal gens gb I)
assert (Q == gQ)

output

i1 : R = ZZ[x,y,z]

o1 = R

o1 : PolynomialRing

i2 : 
     I = ideal(17*x*z+10*x-43,41*x*y-16*x,47*z^2-2*z)

                                              2
o2 = ideal (17x*z + 10x - 43, 41x*y - 16x, 47z  - 2z)

o2 : Ideal of R

i3 : J = ideal( 34*x-16,-2*y*z,-20)

o3 = ideal (34x - 16, -2y*z, -20)

o3 : Ideal of R

i4 : 
     Q = quotient(J, I)

o4 = ideal (20, 2x - 8)

o4 : Ideal of R

i5 : gQ = quotient(ideal gens gb J,ideal gens gb I)

o5 = ideal (20, 2x - 8, 2y*z)

o5 : Ideal of R

i6 : assert (Q == gQ)

i7 : stdio:8:1:(3): error: assertion failed

[DanGrayson]

It fails also in our latest version. Thanks for the bug report!

On Tue Dec 09 2014 at 1:24:36 PM jakobkroeker notifications@github.com wrote:

the following example fails (at least in M2 1.6)

R = ZZ[x,y,z]

I = ideal(17_x_z+10_x-43,41_x_y-16_x,47_z^2-2_z) J = ideal( 34_x-16,-2_y*z,-20)

Q = quotient(J, I) gQ = quotient(ideal gens gb J,ideal gens gb I) assert (Q == gQ)

output

i1 : R = ZZ[x,y,z]

o1 = R

o1 : PolynomialRing

i2 : I = ideal(17_x_z+10_x-43,41_x_y-16_x,47_z^2-2_z)

                                          2

o2 = ideal (17x_z + 10x - 43, 41x_y - 16x, 47z - 2z)

o2 : Ideal of R

i3 : J = ideal( 34_x-16,-2_y*z,-20)

o3 = ideal (34x - 16, -2y*z, -20)

o3 : Ideal of R

i4 : Q = quotient(J, I)

o4 = ideal (20, 2x - 8)

o4 : Ideal of R

i5 : gQ = quotient(ideal gens gb J,ideal gens gb I)

o5 = ideal (20, 2x - 8, 2y*z)

o5 : Ideal of R

i6 : assert (Q == gQ)

i7 : stdio:8:1:(3): error: assertion failed

— Reply to this email directly or view it on GitHub https://github.com/Macaulay2/M2/issues/203.

[DanGrayson]

The problem is in the last step, which applies trim:

i18 : trim ideal (34*x - 16, -2*y*z, -20)

o18 = ideal (20, 2x - 8)

o18 : Ideal of R

i19 : ideal gens gb ideal (34*x - 16, -2*y*z, -20)

o19 = ideal (20, 2x - 8, 2y*z)

o19 : Ideal of R

i20 : trim ideal gens gb ideal (34*x - 16, -2*y*z, -20)

o20 = ideal (20, 2x - 8, 2y*z)

o20 : Ideal of R

[mikestillman]

Hmm, that might mean it is an engine problem with integer groebner bases, as trim collects information taken during the GB computation.

‘trim’ needs to be rethought in the non-homogeneous case too, since the result isn’t unique anyway, and currently, it sometimes gives much worse answers than simply the Groebner basis.

One way to fix this would be to have ‘trim’ return the ideal generated by the Groebner basis.

On Dec 10, 2014, at 9:44 AM, Daniel R. Grayson notifications@github.com wrote:

The problem is in the last step, which applies trim:

i18 : trim ideal (34_x - 16, -2_y*z, -20)

o18 = ideal (20, 2x - 8)

o18 : Ideal of R

i19 : ideal gens gb ideal (34_x - 16, -2_y*z, -20)

o19 = ideal (20, 2x - 8, 2y*z)

o19 : Ideal of R

i20 : trim ideal gens gb ideal (34_x - 16, -2_y*z, -20)

o20 = ideal (20, 2x - 8, 2y*z)

o20 : Ideal of R — Reply to this email directly or view it on GitHub.

[jakobkroeker]

@mikestillman

could you provide a workaround for trim in the meanwhile before a fix is available?

[mikestillman]

Fixed in commit 172cdeff2214f639586facd5a59455df8b57c5db.

The logic for knowing when all original generators have been considered (during a GB computation, to find a small set of generators, called incorrectly "mingens" in some cases) was incorrect over ZZ in some instances. The code has been changed so the logic is more transparent (and correct!).