Update Singular to 4.0.3p4

[jakobkroeker]

This new version does not needed autoreconfing. Nonetheless we still need to ship in the doc and to touch the autotools files due to timestamp issues.

Repackaged tarball at: ​https://perso.telecom-paristech.fr/~flori/singular-4.0.3p4.tar.bz2

[jakobkroeker]

now xalloc should be autoconfigured upstream, see ​https://github.com/Singular/Sources/pull/795

[jpflori]

New upstream tarball:

• ​http://www.mathematik.uni-kl.de/ftp/pub/Math/Singular/SOURCES/4-0-3/singular-4.0.3p4.tar.gz

4.0.4 should be out soon including a fix needed for NTL 10+.

[jpflori]

There is also the segfault mentioned by François at ​https://trac.sagemath.org/ticket/21676#comment:11 when calling singular kernel function.

At the time of cleaning up, it seems we end up with a ring set to NULL and call p_Delete with that at

• ​https://github.com/Singular/Sources/blob/spielwiese/libpolys/polys/simpleideals.cc#L133

[jpflori]

With the previous version merge with trac/develop, no issue.

[fbissey]

Replying to jpflori:

With the previous version merge with trac/develop, no issue.

What do you mean by this?

[jpflori]

Sorry, I typed too fast. This makes no sense. The singular update to 4.0.3p3 + fixes is currently in trac/develop.

[fbissey]

In sage-on-gentoo I actually shipped 7.4 with singular 4.0.3p3 which indeed works fine. So the behavior with 4.0.3p4 was a big shock.

[jpflori]

Yes the issue arises when deallocating from singular the args passed to the mres function (I would say a list of vectors with ring set to NULL). Didn't find out yet what changed. Hopefully I'll be successfull tomorrow.

[jpflori]

Here is what changed:

• in 4.0.3p3 sleftv::CleanUp was called from iiExpr2Arith with ring set and then once again in Sage's handle_call method without a ring set but on a empty sleftv which just did nothing
• in 4.0.3p4 it is only called the second time on a non-empty leftv without a ring set and boom.

[jpflori]

Here you go:

• ​https://github.com/Singular/Sources/commit/86ce458e1269a1d57e682c12b9154dd1f1459354

[jpflori]

Ask for advice here:

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

[jpflori]

New commits:

​4378994	Update singular to 4.0.3p4.
​b191d91	Don't clean up args to singular function without a ring set.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​657fac9

Different Singular printing for ordering.

[jpflori]

Still issues with matrix ordering... Maybe my comment here:

• ​https://trac.sagemath.org/ticket/17254#comment:157

Was not so wrong. But there is also

• ​https://trac.sagemath.org/ticket/17254#comment:196

and

• ​https://trac.sagemath.org/ticket/17254#comment:199

See also:

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

[jpflori]

Looks like both issues about "local/mixed" and total degree are related to this commit:

• ​https://github.com/Singular/Sources/commit/45f4b2d83e0b667a78f6a5d22c428bf88f28fca7

and commits following it. Now the p_WTotalDegree function gives negative results so the Sage hackish code returns -1.

[jpflori]

In fact we now end up in a "very bad" block because of the matrix entries set to 0:

• ​https://github.com/Singular/Sources/commit/0d91221c4a45f7a2621d280d09e628b3e963a60d#diff-d09c8493af07f5c7209a8ad3ce8842feR3826

  +          else
  +          {
  +            // very bad:
  +            nonpos++;
  +            nonneg++;
  +            found=1;
  +          }
  

which leads to OrdSgn = -1 (and MixedOrd = 1) whereas before we had OrdSgn = -1.

Not sure what should happen when matrix ordering has zeros inside. CC'ing knowledgeable people...

[jpflori]

Opened

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

for discussion.

[jpflori]

There is also:

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

suggesting to use p_FDeg or p_LDeg`.

[john_perry]

Replying to jpflori:

Not sure what should happen when matrix ordering has zeros inside.

If the first nonzero element in each column is positive, the ordering is global. From the comments, it says they look at "other blocks." I don't remember offhand how wvhdl works in this case (not sure I ever knew) but it's not clear to me they're looking further down the column than the first row. If not, that would be a bug.

[jpflori]

What is sure is that in the case

            sage: tord = TermOrder(matrix([3,0,1,1,1,0,1,0,0]))

singular gets a OrdSgn = -1 now.

And I get

sage: tord=TermOrder(matrix([3,0,1,1,1,0,1,0,0]))
sage: R.<x,y,z> = PolynomialRing(QQ,3,order=tord)
sage: x.parent()._singular_()

polynomial ring, over a field, mixed ordering
//   characteristic : 0
//   number of vars : 3
//        block   1 : ordering M
//                  : names    x y z
//                  : weights  3 0 1
//                  : weights  1 1 0
//                  : weights  1 0 0
//        block   2 : ordering C
sage: 

[jpflori]

It also depends on what you mean by positive...

[jpflori]

Form the "very bad" snippet, any zero entry (in at least the first row) makes it a mixed ordering.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​eef0dc4

Use Singular p_WDegree for weighted degree.

[jpflori]

It seems most failing doctests are gone.

• Fatal: Memory exhausted in sage -t --long src/sage/modular/local_comp/type_space.py which might be unrelated.

[jpflori]

I can confirm the above issue also happends without the update to 4.0.3p4 so it should not prevent this ticket from being merged.

[jdemeyer]

1. I think it's better to keep the touching in spkg-src instead of moving it to spkg-install.

2. Why this change? You don't seem to use the newly-cimported stuff

   src/sage/libs/singular/polynomial.pyx

   @@ -22 +22 @@
    from sage.libs.singular.decl cimport number, ideal
    from sage.libs.singular.decl cimport currRing, rChangeCurrRing
    from sage.libs.singular.decl cimport p_Copy, p_Add_q, p_Neg, pp_Mult_nn, p_GetCoeff, p_IsConstant, p_Cmp, pNext
   -from sage.libs.singular.decl cimport p_GetMaxExp, pp_Mult_qq, pPower, p_String, p_GetExp, p_Deg, p_Totaldegree, p_WTotaldegree, p_WDegree
   +from sage.libs.singular.decl cimport p_GetMaxExp, pp_Mult_qq, pPower, p_String, p_GetExp, p_Deg, p_Totaldegree, p_WTotaldegree, p_WDegree, p_LDeg, p_FDeg
    from sage.libs.singular.decl cimport n_Delete, idInit, fast_map_common_subexp, id_Delete
    from sage.libs.singular.decl cimport omAlloc0, omStrDup, omFree
    from sage.libs.singular.decl cimport p_GetComp, p_SetComp

3. Remove this: #return p_Deg(p, r)

[fbissey]

The current patch works for me to solve the segfault problems. Pending the revisions asked by Jeroen, I am ok with this.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​10b99df

Remove unused Singular degree related stuff.

[jpflori]

Points 2 and 3 addressed.

I can go with point 1 but that means repackaging the tarball. Will the patchbots and Volker be happy?

[jpflori]

I've reported the issue here:

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

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​ff7c145

Touch Singular autotools files in spkg-src.

[jpflori]

Dealt with point 1. The tarball changed.

[fbissey]

Replying to jpflori:

Points 2 and 3 addressed.

I can go with point 1 but that means repackaging the tarball. Will the patchbots and Volker be happy?

Depends whether or not he already uploaded it on the mirrors or not. This hasn't got through his develop branch on github so probably not.

Putting it to positive review.

[fbissey]

Stop! I thought this release was supposed to have the fix for ntl 10+. But it isn't there, in the tarball or the patches directory. Do we want to proceed with that?

[jpflori]

I'd say we merge now and add a patch in the ntl10 ticket #21676. More work will also be needed for a better debug mode #21624 but I need Hans' feedback on that one as there might be some bugs in singular itself.

[vbraun]

There are now a lot more warnings in debug mode but I'll leave that to you in #21624

[jhpalmieri]

See #21865 for a followup.

[jdemeyer]

Did somebody verify that all patches which are removed in this ticket are actually upstreamed in this Singular version? If not, we might have an easy fix for #21865.