LCM in Gröbner basis computation chokes pTest

[Jean-Pierre Flori]

Hi all,

When Singular is built in debug mode (with xalloc), during a Gröbner basis computation, it seems a LCM gets computed from here:
* https://github.com/Singular/Sources/blob/spielwiese/kernel/GBEngine/kutil.cc#L12351

The result looks like:
(gdb) p *m
$40 = {
  next = 0x0,
  coef = 0x0,
  exp = {0}
}
(gdb) p *a
$41 = {
  next = 0x12e61ba8,
  coef = 0x5,
  exp = {1}
}
(gdb) p *b
$42 = {
  next = 0x12e61e98,
  coef = 0x5,
  exp = {0}
}

Then in the isInV call, p_IsConstant calls pTest and chokes giving error output "***dPolyReportError: NULL coef" because the coeff is 0 == NULL rom
* https://github.com/Singular/Sources/blob/spielwiese/libpolys/polys/pDebug.cc#L250

As pLcm does not set coef, it will be 0 in any case, so there is definitely something to be done here.

Best,
JPF

[Jean-Pierre Flori]

The code given in example here:
* https://www.singular.uni-kl.de/Manual/4-0-2/sing_543.htm#SEC594
produces similar warnings/errors about:
* the NULL coeff's,
* and stuff not being where it belongs through kTest_L and kTest_TS.

[Jean-Pierre Flori]

Thanks for fixing the NULL coef warnings.

The ones in Grobner basis computation are still there
(try the example at
* https://www.singular.uni-kl.de/Manual/4-0-2/sing_543.htm#SEC594
)
and the one about minpoly when using the genus function.

We also get a new one which was not there for 4.0.3p3:
> ring r = (integer,2,10),(x,y),dp;

// ***dError: assume violation at numbers.cc:426 condition: n->cfCoeffName!=ndCoeffName


Anyway, thanks a lot for all your work!

[Jean-Pierre Flori]

On Thursday, November 3, 2016 at 1:53:48 PM UTC+1, Jean-Pierre Flori wrote:

We also get a new one which was not there for 4.0.3p3:
> ring r = (integer,2,10),(x,y),dp;

// ***dError: assume violation at numbers.cc:426 condition: n->cfCoeffName!=ndCoeffName

This ones originates here:
* https://github.com/Singular/Sources/commit/c7ae4d6af43fc7bc0e0e28fef427ad316ac3a8ce

[Jean-Pierre Flori]

And I guess changes like here:
* https://github.com/Singular/Sources/commit/9a1960b6e0ed640233d9cfb3dc5fc29208eee68c
are needed.

[Jakob Kroeker]

Dear Hans,

could you please look at the described issue,
since this is a blocker ticket in sage
(https://trac.sagemath.org/ticket/21624)

One failing example is

ring r = 0,(x,y,z),dp;                                                                                                                              
int d =4; // degree bound                                                                                                                           
def R = makeLetterplaceRing(d);                                                                                                                     
setring R;                                                                                                                                          
ideal I = x(1)*y(2) + y(1)*z(2), x(1)*x(2) + x(1)*y(2) - y(1)*x(2) - y(1)*y(2);                                                                     
option(redSB); option(redTail);                                                                                                                     
setring R;
ideal I = x(1)*y(2) + y(1)*z(2), x(1)*x(2) + x(1)*y(2) - y(1)*x(2) - y(1)*y(2);                                                                     
option(redSB); option(redTail);                                                                                                                     
ideal J = letplaceGBasis(I);
//produces error like

// ***dError: S_2_R[2]=1 != T[1].i_r=0

 

Jakob

[Jean-Pierre Flori]

Hi Hans,

On Wednesday, February 1, 2017 at 6:03:21 PM UTC+1, Jakob Kroeker wrote:

ring r = 0,(x,y,z),dp;                                                                                                                              
int d =4; // degree bound                                                                                                                           
def R = makeLetterplaceRing(d);                                                                                                                     
setring R;                                                                                                                                          
ideal I = x(1)*y(2) + y(1)*z(2), x(1)*x(2) + x(1)*y(2) - y(1)*x(2) - y(1)*y(2);                                                                     
option(redSB); option(redTail);                                                                                                                     
setring R;
ideal I = x(1)*y(2) + y(1)*z(2), x(1)*x(2) + x(1)*y(2) - y(1)*x(2) - y(1)*y(2);                                                                     
option(redSB); option(redTail);                                                                                                                     
ideal J = letplaceGBasis(I);
//produces error like

// ***dError: S_2_R[2]=1 != T[1].i_r=0

 

I see you fixed that one! Thanks a lot.
Now I'm left with  // ***dError: L[0].p1 not in T
running the same code.

Could you also have a look?

Best,
JPF

[Jean-Pierre Flori]

Hi Hans,

I guess the last issue might happen because in kTest_L, the kFindInT function uses pointer comparison:
* https://github.com/Singular/Sources/blob/spielwiese/kernel/GBEngine/kutil.cc#L723

The same monomial is in T and L[0].p1 but at different memory addresses.
For T it is appended here i enterTShift:
* https://github.com/Singular/Sources/blob/7d44dd5555e888e65ba7e20c25fc77d0d98f0db1/kernel/GBEngine/kstd2.cc#L4267
And for L it is appended at the next line enterpairsShift:
* https://github.com/Singular/Sources/blob/7d44dd5555e888e65ba7e20c25fc77d0d98f0db1/kernel/GBEngine/kstd2.cc#L4268
At some points it builds the same monomial and put it in B in enterOnePairShift.
Then chainCrit (== chainCritNormal) picks it up in B to put it into L[0].p1 within kMergeBintoL.

I have no idea at the moment what S, T, L and B are for, this is just stupid debugging.

Does it help you Hans?

Best,
JPF

[Jean-Pierre Flori]

On Thursday, February 9, 2017 at 2:11:20 PM UTC+1, Jean-Pierre Flori wrote:

Hi Hans,

I guess the last issue might happen because in kTest_L, the kFindInT function uses pointer comparison:
* https://github.com/Singular/Sources/blob/spielwiese/kernel/GBEngine/kutil.cc#L723

The same monomial is in T and L[0].p1 but at different memory addresses.
For T it is appended here i enterTShift:
* https://github.com/Singular/Sources/blob/7d44dd5555e888e65ba7e20c25fc77d0d98f0db1/kernel/GBEngine/kstd2.cc#L4267
And for L it is appended at the next line enterpairsShift:
* https://github.com/Singular/Sources/blob/7d44dd5555e888e65ba7e20c25fc77d0d98f0db1/kernel/GBEngine/kstd2.cc#L4268
At some points it builds the same monomial and put it in B in enterOnePairShift.

The copy is built here with p_LPshiftT with j = 1:
* https://github.com/Singular/Sources/blob/spielwiese/kernel/GBEngine/kutil.cc#L12294
called through
 #1  0x00000000101f3ebc in enterOnePairSelfShifts (qq=0x107125b8, p=0x107125b8,
    ecart=0, isFromQ=0, strat=0x1071ce08, uptodeg=4, lV=3) at kutil.cc:12305
#2  0x00000000101f4ff4 in initenterpairsShift (h=0x107125b8, k=0, ecart=0,
    isFromQ=0, strat=0x1071ce08, atR=3, uptodeg=4, lV=3) at kutil.cc:12678
#3  0x00000000101f4ba0 in enterpairsShift (h=0x107125b8, k=0, ecart=0, pos=1,
    strat=0x1071ce08, atR=3, uptodeg=4, lV=3) at kutil.cc:12615
#4  0x00000000101ae69c in bbaShift (F=0x107228a8, Q=0x0, w=0x0, hilb=0x0,
    strat=0x1071ce08, uptodeg=4, lV=3) at kstd2.cc:4268

[Jean-Pierre Flori]

More generally, is there any reason to expect what is put into B and then put into L to already be in T?

[Jean-Pierre Flori]

The comment here looks relevant:
* https://github.com/Singular/Sources/blame/spielwiese/kernel/GBEngine/kutil.cc#L12576

/* TEMPORARILY DISABLED FOR SHIFTS because there's no i*/ /* at the beginning we DO NOT set atR = -1 ANYMORE*/

[Jean-Pierre Flori]

It indeed seems that any call to kTest_L with lpos > -1 leads to such an error.

[Jean-Pierre Flori]

I've made a pull request with modifs to try to mitigate this issue.