Better debug mode for singular 4

[jpflori]

This is a follow up to #17254 which upgraded to singular 4:

• debug (with xalloc) build on OS X (om_Info gets undefined (U) in Singular, note that it is ok on linux (B), maybe depends on ocmpiler, linker vesions)
• failing test in debug mode

[vbraun]

24524sage -t --long src/sage/algebras/free_algebra.py  # 4 doctests failed
24525sage -t --long src/sage/algebras/letterplace/free_algebra_element_letterplace.pyx  # 6 doctests failed
24526sage -t --long src/sage/algebras/letterplace/free_algebra_letterplace.pyx  # 2 doctests failed
24527sage -t --long src/sage/algebras/letterplace/letterplace_ideal.pyx  # 10 doctests failed
24528sage -t --long src/sage/rings/quotient_ring.py  # 18 doctests failed
24529sage -t --long src/sage/rings/quotient_ring_element.py  # 1 doctest failed
24530sage -t --long src/sage/schemes/curves/constructor.py  # 1 doctest failed

[jpflori]

All of these errors look like:

    // ***dPolyReportError: NULL coef 
     occurred at
     occurred for poly: o*x*y*x_1*y_1*x_2
    // ***dPolyReportError: NULL coef 
     occurred at
     occurred for poly: o*y*x_1*y_1*x_2
    // ***dError: S_2_R[2]=1 != T[1].i_r=0
    -y*z*x - y*z*y - y*z*z

except for the last one:

File "src/sage/schemes/curves/constructor.py", line 108, in sage.schemes.curves.constructor.Curve
Failed example:
    C.genus()
Expected:
    13
Got:
    // ** no minpoly allowed if there are local objects belonging to the basering: 
    number((a2+a+1))
    // ** killing a local object due to minpoly change: p
    // ** no minpoly allowed if there are local objects belonging to the basering: 
    number((a2-a+1))
    // ** killing a local object due to minpoly change: p
    13

24528sage -t --long src/sage/rings/quotient_ring.py # 18 doctests failed 24529sage -t --long src/sage/rings/quotient_ring_element.py # 1 doctest failed 24530sage -t --long src/sage/schemes/curves/constructor.py # 1 doctest failed }}}

[jpflori]

Thread about first issue here:

• ​https://groups.google.com/forum/#!topic/libsingular-devel/TPZNlvZXei0

[jpflori]

And the second one here:

• ​https://groups.google.com/forum/#!topic/libsingular-devel/tYuWlGOZdWo

[vbraun]

With #21631 there are now also many

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

warnings, though no crashes.

[jpflori]

Can you tell in which file it is?

[jpflori]

Ok, got it.

[jpflori]

See ##21865 for new errors occurring only in debug mode in:

• sage/rings/cfinite_sequence.py
• sage/matrix/matrix_modn_dense_template.pxi

[jakobkroeker]

the last issue ( "no minpoly allowed..") can be fixed with

​https://github.com/Singular/Sources/pull/814 (avoids intermediate object between ring declaration and minpoly definition in 'normal.lib')

Did you get answers from Hans for the other issues? Or, could you track them down?

Replying to jpflori:

All of these errors look like:

    // ***dPolyReportError: NULL coef 
     occurred at
     occurred for poly: o*x*y*x_1*y_1*x_2
    // ***dPolyReportError: NULL coef 
     occurred at
     occurred for poly: o*y*x_1*y_1*x_2
    // ***dError: S_2_R[2]=1 != T[1].i_r=0
    -y*z*x - y*z*y - y*z*z

except for the last one:

File "src/sage/schemes/curves/constructor.py", line 108, in sage.schemes.curves.constructor.Curve
Failed example:
    C.genus()
Expected:
    13
Got:
    // ** no minpoly allowed if there are local objects belonging to the basering: 
    number((a2+a+1))
    // ** killing a local object due to minpoly change: p
    // ** no minpoly allowed if there are local objects belonging to the basering: 
    number((a2-a+1))
    // ** killing a local object due to minpoly change: p
    13

24528sage -t --long src/sage/rings/quotient_ring.py # 18 doctests failed 24529sage -t --long src/sage/rings/quotient_ring_element.py # 1 doctest failed 24530sage -t --long src/sage/schemes/curves/constructor.py # 1 doctest failed }}}

[jakobkroeker]

Replying to vbraun:

With #21631 there are now also many

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

warnings, though no crashes.

so changes in #21631 introduced a new issue? Could someone track it down?

[jpflori]

Replying to jakobkroeker:

Replying to vbraun:

With #21631 there are now also many

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

warnings, though no crashes.

so changes in #21631 introduced a new issue? Could someone track it down?

This has been fixed in Singular git version.

[jpflori]

Replying to jakobkroeker:

the last issue ( "no minpoly allowed..") can be fixed with

​https://github.com/Singular/Sources/pull/814 (avoids intermediate object between ring declaration and minpoly definition in 'normal.lib')

Good! It's even in Singular's git version now.

Did you get answers from Hans for the other issues? Or, could you track them down?

Replying to jpflori:

All of these errors look like:

     occurred at
     occurred for poly: o*y*x_1*y_1*x_2
    // ***dError: S_2_R[2]=1 != T[1].i_r=0
    -y*z*x - y*z*y - y*z*z

Those like this were still present last time I checked and those about stuff not being where it belongs through kTest_L and kTest_TS as mentioned here:

• ​https://groups.google.com/d/msg/libsingular-devel/TPZNlvZXei0/CptSq0fdAgAJ

No feedback from Hans and I had no time to look at it.

[jakobkroeker]

I just reminded Hans kindly to look at that issue since it is a blocker ticket for sage.

​https://groups.google.com/forum/#!msg/libsingular-devel/TPZNlvZXei0/CptSq0fdAgAJ

Let's see if something happens.

Replying to jpflori:

Replying to jakobkroeker:

the last issue ( "no minpoly allowed..") can be fixed with

​https://github.com/Singular/Sources/pull/814 (avoids intermediate object between ring declaration and minpoly definition in 'normal.lib')

Good! It's even in Singular's git version now.

Did you get answers from Hans for the other issues? Or, could you track them down?

Replying to jpflori:

All of these errors look like:

     occurred at
     occurred for poly: o*y*x_1*y_1*x_2
    // ***dError: S_2_R[2]=1 != T[1].i_r=0
    -y*z*x - y*z*y - y*z*z

Those like this were still present last time I checked and those about stuff not being where it belongs through kTest_L and kTest_TS as mentioned here:

• ​https://groups.google.com/d/msg/libsingular-devel/TPZNlvZXei0/CptSq0fdAgAJ

No feedback from Hans and I had no time to look at it.

[jpflori]

With the latest tarball for 4-1-0p2, debug mode should be clean:

• ​http://www.mathematik.uni-kl.de/ftp/pub/Math/Singular/SOURCES/4-1-0/

[jakobkroeker]

Replying to jpflori:

With the latest tarball for 4-1-0p2, debug mode should be clean:

• ​http://www.mathematik.uni-kl.de/ftp/pub/Math/Singular/SOURCES/4-1-0/

related singular commit is ​https://github.com/Singular/Sources/commit/54c80cb81ed58f166a023fc060f541e24ebd5892

[jakobkroeker]

Replying to jpflori:

Replying to jakobkroeker:

the last issue ( "no minpoly allowed..") can be fixed with

​https://github.com/Singular/Sources/pull/814 (avoids intermediate object between ring declaration and minpoly definition in 'normal.lib')

Good! It's even in Singular's git version now.

There are much more issues in Singular LIBs where the minpoly is not immediately defined (and lead to debug output) which are probably not hit by current sage tests, but in the long term they have all to be fixed: ​https://github.com/jakobkroeker/test_singular/issues/243

[embray]

I think I'm seeing this too. I almost always compile with SAGE_DEBUG=yes on Cygwin since I have to debug things so often, and I'm seeing lots of failures like this since the switch to Singular 4. Going to recompile Singular in non-debug mode to confirm that it goes away.

(Also obviously this isn't a blocker or it'd be fixed by now :)

[embray]

Confirmed that rebuilding Singular and its dependents with SAGE_DEBUG=no fixed these failures for me.

[jpflori]

@eric: does #22425 fixed the errors you saw? I think we can close this one now #22425 is merged.

[embray]

I don't think I've tried yet. I'll test it and see. Are you saying it should be fixed even with SAGE_DEBUG=yes?

[jpflori]

All error messages specific to singular built in debug mode should not appear anymore.

[jpflori]

Should be ok since the latest singular upgrade.

[vbraun]

I'm still getting this one

sage -t --long src/sage/interfaces/singular.py
**********************************************************************
File "src/sage/interfaces/singular.py", line 1523, in sage.interfaces.singular.SingularElement.sage_global_ring
Failed example:
    singular.eval('ring r5 = (complex,15,j),(a,b,c),dp')
Expected:
    ''
Got:
    '\n// ***dError: assume violation at numbers.cc:434 condition: n->cfCoeffName!=ndCoeffName'
**********************************************************************
1 item had failures:
   1 of  22 in sage.interfaces.singular.SingularElement.sage_global_ring
    [390 tests, 1 failure, 10.81 s]

[jpflori]

Maybe #22868. Did not check debug mode there.

[jpflori]

Unfortunately the failing test it is still here with 4.1.0p3.

[jpflori]

Should be fixed in git version:

• ​https://github.com/Singular/Sources/commit/6af76a7a09a49e7e08065cdf078b2461e16af2eb

@volker: do you see any other failures?

[vbraun]

These look a bit like they might be from Singular, haven't investigated further:

sage -t --long src/sage/rings/polynomial/multi_polynomial_ideal.py
**********************************************************************
File "src/sage/rings/polynomial/multi_polynomial_ideal.py", line 1761, in sage.rings.polynomial.multi_polynomial_ideal.?.interreduced_basis
Failed example:
    Ideal(P(0)).interreduced_basis()
Expected:
    [0]
Got:
    wrong mod p number 140727535500960 at modulop.cc,158
    [0]
**********************************************************************
1 item had failures:
   1 of  13 in sage.rings.polynomial.multi_polynomial_ideal.?.interreduced_basis
    [722 tests, 1 failure, 75.81 s]
sage -t --long src/sage/rings/polynomial/multi_polynomial_sequence.py
**********************************************************************
File "src/sage/rings/polynomial/multi_polynomial_sequence.py", line 1022, in sage.rings.polynomial.multi_polynomial_sequence.PolynomialSequence_generic.reduced
Failed example:
    Sequence([P(0)]).reduced()
Expected:
    [0]
Got:
    wrong mod p number 140727535505680 at modulop.cc,158
    [0]
**********************************************************************
1 item had failures:
   1 of  17 in sage.rings.polynomial.multi_polynomial_sequence.PolynomialSequence_generic.reduced
    [235 tests, 1 failure, 14.47 s]

[jpflori]

Error messages definitely from Singular, though it might be from bad input on Sage's side.