Opened 2 years ago

Last modified 6 days ago

#25993 needs_work enhancement

Upgrade Singular

Reported by: jdemeyer Owned by:
Priority: critical Milestone: sage-9.3
Component: packages: standard Keywords: upgrade, Singular
Cc: SimonKing, gh-timokau, slelievre, isuruf, saraedum, dkrenn, araichev, cheuberg, behackl, dimpase Merged in:
Authors: Antonio Rojas, Markus Wageringel, Matthias Koeppe Reviewers: Matthias Koeppe, ...
Report Upstream: Reported upstream. Developers acknowledge bug. Work issues:
Branch: public/singular4-1-3 (Commits) Commit: 62dfd9aaf7778fb8823a8b6a7f02603b62ca40a5
Dependencies: #30588 Stopgaps:

Description (last modified by gh-mwageringel)

Tarball 4.1.3p2: ftp://jim.mathematik.uni-kl.de/pub/Math/Singular/SOURCES/4-1-3/singular-4.1.3p2.tar.gz

Use make SAGE_SPKG="sage-spkg -o" singular-clean sagelib-clean build to automatically download and install.

Change History (120)

comment:1 Changed 2 years ago by jdemeyer

  • Dependencies set to #24735

comment:2 Changed 2 years ago by jdemeyer

  • Cc SimonKing gh-timokau added
  • Description modified (diff)

comment:3 Changed 2 years ago by jdemeyer

  • Branch set to u/jdemeyer/ticket/25993

comment:4 Changed 2 years ago by jdemeyer

  • Commit set to ec53e6fadfe9cb22a70029f4b9c91576c6c2b1d3
  • Description modified (diff)

Last 10 new commits:

0f55b76More real -> Float porting
aea0544Don't check for exact Singular version
4e52b5eUse p_Divide for lcm as suggested by upstream
50b9ae2Backport patch to move singular's NTL handling out of libsingular
7b56ef2Document patch
930ba2eRemove duplicate cimport
f31d9daMove patch documentation inside patch itself
07ef11brest -> reminder
a9e5aedMinor fixes to Singular interface
ec53e6fUpgrade to Singular 4.1.1p3

comment:5 follow-up: Changed 2 years ago by SimonKing

Sigh. So I have to upgrade the group cohomology package earlier than I thought. I'll see what I can do (after grading some exam).

comment:6 follow-up: Changed 2 years ago by SimonKing

The ticket description prominently tells that the group cohomology package is failing, but the title of the ticket is about upgrading Singular.

So, just to be sure about the topic of this ticket:

  • Is this ticket about upgrading Singular, which means that a new ticket for upgrading the group cohomology package needs to be created? If this is so, which of the tickets should depend on the other?
  • Is this ticket only about upgrading the group cohomology package? Looking at the commits, I suppose that this is not the case.

comment:7 in reply to: ↑ description Changed 2 years ago by SimonKing

Replying to jdemeyer:

It's not clear to me whether this is a Singular bug or a p_group_cohomology bug.

Most likely it is an API change.

comment:8 in reply to: ↑ 6 ; follow-up: Changed 2 years ago by jdemeyer

This ticket is about upgrading Singular. If the p_group_cohomology package must be changed, ideally it should be done in a way which makes it compatible both with Singular 4.1.1p3 as well as earlier versions. In that case, the upgrade of p_group_cohomology can be done on a different ticket and #25993 should depend on that.

Concerning the commit history, only the last commit belongs to this ticket. The rest belongs to #24735 which is an upgrade of Singular to 4.1.1p2.

comment:9 in reply to: ↑ 8 ; follow-up: Changed 2 years ago by SimonKing

Replying to jdemeyer:

Concerning the commit history, only the last commit belongs to this ticket. The rest belongs to #24735 which is an upgrade of Singular to 4.1.1p2.

I see. Do you know if the breakage already happens in p2?

comment:10 follow-up: Changed 2 years ago by SimonKing

PS: I recently added a patch to Singular which backports a bugfix that is important to me. Is that bugfix in Singular-4.1.1?

comment:11 in reply to: ↑ 9 ; follow-up: Changed 2 years ago by jdemeyer

Replying to SimonKing:

I see. Do you know if the breakage already happens in p2?

I know that it does not occur. That's also a good reason to do the upgrade in two steps: first to 4.1.1p2 which works fine and then to 4.1.1p3 (or a later version) once p_group_cohomology is fixed.

comment:12 in reply to: ↑ 11 Changed 2 years ago by SimonKing

Replying to jdemeyer:

Replying to SimonKing:

I see. Do you know if the breakage already happens in p2?

I know that it does not occur. That's also a good reason to do the upgrade in two steps: first to 4.1.1p2 which works fine and then to 4.1.1p3 (or a later version) once p_group_cohomology is fixed.

Thank you! That sounds like a good plan. And do you know about the backported bug fix?

comment:13 in reply to: ↑ 10 ; follow-up: Changed 2 years ago by jdemeyer

Replying to SimonKing:

I recently added a patch to Singular which backports a bugfix that is important to me. Is that bugfix in Singular-4.1.1?

That's hard to say if you don't say which patch you mean. In any case, all patches which are currently (in Sage 8.3.rc3) applied to Singular are included in Singular 4.1.1p2.

Note that you said 4.1.1 but I guess you really care about 4.1.1p2 or 4.1.1p3. Despite what the version numbers suggest, experience shows that Singular adds non-trivial changes in such patch-releases.

comment:14 in reply to: ↑ 13 ; follow-ups: Changed 2 years ago by SimonKing

Replying to jdemeyer:

Replying to SimonKing:

I recently added a patch to Singular which backports a bugfix that is important to me. Is that bugfix in Singular-4.1.1?

That's hard to say if you don't say which patch you mean. In any case, all patches which are currently (in Sage 8.3.rc3) applied to Singular are included in Singular 4.1.1p2.

It is backport_std.patch

Note that you said 4.1.1 but I guess you really care about 4.1.1p2 or 4.1.1p3. Despite what the version numbers suggest, experience shows that Singular adds non-trivial changes in such patch-releases.

I see. I thought that the "p something" patch level is Sage's addition of patches, not Singular's.

comment:15 Changed 2 years ago by jdemeyer

  • Description modified (diff)
  • Report Upstream changed from N/A to Fixed upstream, but not in a stable release.

comment:16 in reply to: ↑ 14 Changed 2 years ago by jdemeyer

Replying to SimonKing:

I see. I thought that the "p something" patch level is Sage's addition of patches, not Singular's.

No, Sage's p levels have a dot. So you can have a Singular package version number like 4.1.1p2.p0 (where 4.1.1p2 comes from Singular upstream and .p0 from Sage). I know, it's confusing :-)

comment:17 Changed 2 years ago by git

  • Commit changed from ec53e6fadfe9cb22a70029f4b9c91576c6c2b1d3 to 83c8ac26d40bfa342d4fe37d43ec9db84e1055ba

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

83c8ac2Upgrade to Singular 4.1.1p3

comment:18 in reply to: ↑ 14 ; follow-up: Changed 2 years ago by jdemeyer

Replying to SimonKing:

It is backport_std.patch

Sorry, I don't know what you mean. Where should I find this patch?

comment:19 in reply to: ↑ 18 Changed 2 years ago by SimonKing

Replying to jdemeyer:

Replying to SimonKing:

It is backport_std.patch

Sorry, I don't know what you mean. Where should I find this patch?

#25889

comment:20 in reply to: ↑ 5 Changed 2 years ago by jdemeyer

Replying to SimonKing:

Sigh. So I have to upgrade the group cohomology package earlier than I thought.

At least this time, it's not the fault of Sage but Singular :-)

comment:21 Changed 2 years ago by SimonKing

  • Dependencies changed from #24735 to #24735 #26001

I created #26001 to deal with the now needed upgrade of the group cohomology package. I suggest that I bae #26001 on top of #24735 (which by now is positively reviewed) and make the new ticket a dependency for the upgrade of Singular to version 4.1.1.p3.

comment:22 Changed 2 years ago by gh-timokau

Is this supposed to pass the non-optional doctests already? I cherry-picket the last two commits (Upgrade to Singular 4.1.1p3 and Minor fixes to Singular interface) and added the patch to singular in an attempt to update nix's Singular to p3. I'm getting a segfault while running the doctests:

File "/nix/store/pzc940fjxrhq17j58krwry2y7wi9czh8-sage-src-8.3/src/sage/rings/polynomial/plural.pyx", line 396, in sage.rings.polynomial.plural.NCPolynomialRing_plural.__dealloc__
Failed example:
    R2 = A2.g_algebra({y*x:x*y-z, z*x:x*z+2*x, z*y:y*z-2*y}, order=TermOrder('degrevlex', 2))
Exception raised:
    Traceback (most recent call last):
      File "/nix/store/ic3b215ln47d0js46lyvc7zjizd9jfqp-python-2.7.15-env/lib/python2.7/site-packages/sage/doctest/forker.py", line 573, in _run
        self.compile_and_execute(example, compiler, test.globs)
      File "/nix/store/ic3b215ln47d0js46lyvc7zjizd9jfqp-python-2.7.15-env/lib/python2.7/site-packages/sage/doctest/forker.py", line 983, in compile_and_execute
        exec(compiled, globs)
      File "<doctest sage.rings.polynomial.plural.NCPolynomialRing_plural.__dealloc__[6]>", line 1, in <module>
        R2 = A2.g_algebra({y*x:x*y-z, z*x:x*z+Integer(2)*x, z*y:y*z-Integer(2)*y}, order=TermOrder('degrevlex', Integer(2)))
      File "/nix/store/ic3b215ln47d0js46lyvc7zjizd9jfqp-python-2.7.15-env/lib/python2.7/site-packages/sage/algebras/free_algebra.py", line 876, in g_algebra
        order=order, check=check)
      File "sage/structure/factory.pyx", line 368, in sage.structure.factory.UniqueFactory.__call__ (build/cythonized/sage/structure/factory.c:2046)
        return self.get_object(version, key, kwds)
      File "sage/structure/factory.pyx", line 411, in sage.structure.factory.UniqueFactory.get_object (build/cythonized/sage/structure/factory.c:2422)
        obj = self.create_object(version, key, **extra_args)
      File "sage/rings/polynomial/plural.pyx", line 173, in sage.rings.polynomial.plural.G_AlgFactory.create_object (build/cythonized/sage/rings/polynomial/plural.cpp:5046)
        return NCPolynomialRing_plural(base_ring, names, c, d, order,
      File "sage/rings/polynomial/plural.pyx", line 351, in sage.rings.polynomial.plural.NCPolynomialRing_plural.__init__ (build/cythonized/sage/rings/polynomial/plural.cpp:6406)
        test = ff.nctools__lib.ndcond(ring = self)
      File "sage/libs/singular/function.pyx", line 1330, in sage.libs.singular.function.SingularFunction.__call__ (build/cythonized/sage/libs/singular/function.cpp:15332)
        return call_function(self, args, ring, interruptible, attributes)
      File "sage/libs/singular/function.pyx", line 1512, in sage.libs.singular.function.call_function (build/cythonized/sage/libs/singular/function.cpp:17285)
        with opt_ctx: # we are preserving the global options state here
      File "sage/libs/singular/function.pyx", line 1514, in sage.libs.singular.function.call_function (build/cythonized/sage/libs/singular/function.cpp:17197)
        sig_on()
    SignalError: Segmentation fault

comment:23 Changed 2 years ago by arojas

Note that this will also break the build of polymake (not sure if it affects the 3.1 version shipped by Sage)

http://www.singular.uni-kl.de:8002/trac/ticket/838

comment:24 Changed 2 years ago by fbissey

  • Milestone changed from sage-8.4 to sage-8.5

comment:25 follow-up: Changed 22 months ago by arojas

4.1.1p4 is out, with fixes for the gcd in ZZ and the polymake issue. But (of course) with new problems: the stest function has changed signature and now only accepts two parameters [1]. After porting the Sage code I'm getting floating point exceptions

File "/usr/lib/python2.7/site-packages/sage/rings/quotient_ring_element.py", line 629, in sage.rings.quotient_ring_element.QuotientRingElement._richcmp_
Failed example:
    I = F*[x*y+y*z,x^2+x*y-y*x-y^2]*F
Exception raised:
    Traceback (most recent call last):
      File "/usr/lib/python2.7/site-packages/sage/doctest/forker.py", line 671, in _run
        self.compile_and_execute(example, compiler, test.globs)
      File "/usr/lib/python2.7/site-packages/sage/doctest/forker.py", line 1086, in compile_and_execute
        exec(compiled, globs)
      File "<doctest sage.rings.quotient_ring_element.QuotientRingElement._richcmp_[7]>", line 1, in <module>
        I = F*[x*y+y*z,x**Integer(2)+x*y-y*x-y**Integer(2)]*F
      File "sage/structure/element.pyx", line 1517, in sage.structure.element.Element.__mul__ (build/cythonized/sage/structure/element.c:12022)
        return (<Element>left)._mul_(right)
      File "sage/algebras/letterplace/free_algebra_element_letterplace.pyx", line 604, in sage.algebras.letterplace.free_algebra_element_letterplace.FreeAlgebraElement_letterplace._mul_ (build/cythonized/sage/algebras/letterplace/free_algebra_element_letterplace.cpp:9487)
        rshift = singular_system("stest",right._poly,left._poly.degree(), ring=A._current_ring)
      File "sage/libs/singular/function.pyx", line 1330, in sage.libs.singular.function.SingularFunction.__call__ (build/cythonized/sage/libs/singular/function.cpp:15055)
        return call_function(self, args, ring, interruptible, attributes)
      File "sage/libs/singular/function.pyx", line 1512, in sage.libs.singular.function.call_function (build/cythonized/sage/libs/singular/function.cpp:16879)
        with opt_ctx: # we are preserving the global options state here
      File "sage/libs/singular/function.pyx", line 1514, in sage.libs.singular.function.call_function (build/cythonized/sage/libs/singular/function.cpp:16791)
        sig_on()
    FloatingPointError: Floating point exception

[1] https://github.com/Singular/Sources/commit/b00f8a34fb50dbff4746ce45d0680d242f28260c

comment:26 in reply to: ↑ 25 ; follow-up: Changed 22 months ago by jdemeyer

Replying to arojas:

4.1.1p4 is out

Really? I don't see it on ftp://jim.mathematik.uni-kl.de/pub/Math/Singular/SOURCES/4-1-1/

comment:27 in reply to: ↑ 26 Changed 22 months ago by arojas

Replying to jdemeyer:

Replying to arojas:

4.1.1p4 is out

Really? I don't see it on ftp://jim.mathematik.uni-kl.de/pub/Math/Singular/SOURCES/4-1-1/

That mirror seems to be outdated

https://service.mathematik.uni-kl.de/ftp/pub/Math/Singular/SOURCES/4-1-1/

comment:28 Changed 22 months ago by jdemeyer

  • Dependencies changed from #24735 #26001 to #26001
  • Description modified (diff)
  • Summary changed from Upgrade to Singular 4.1.1p3 to Upgrade to Singular 4.1.1p4

comment:29 follow-up: Changed 22 months ago by SimonKing

Can you test if it is also breaking the new version of p_group_cohomology (see #26001), which is ready for review?

comment:30 in reply to: ↑ 29 Changed 22 months ago by SimonKing

Replying to SimonKing:

Can you test if it is also breaking the new version of p_group_cohomology (see #26001), which is ready for review?

I did test: The upgrade to singular-4.1.1p3 is not problematic with the new version of p_group_cohomology. I cannot tell about p4, of course.

Anyway, some good news for the start of the new year...

comment:31 Changed 21 months ago by jdemeyer

  • Dependencies #26001 deleted
  • Description modified (diff)

comment:32 Changed 21 months ago by jdemeyer

  • Description modified (diff)
  • Report Upstream changed from Fixed upstream, but not in a stable release. to N/A

comment:33 Changed 21 months ago by git

  • Commit changed from 83c8ac26d40bfa342d4fe37d43ec9db84e1055ba to 4bd32fe685b58802a56a8a6cb4e75b9abe02e94b

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

4bd32feUpgrade to Singular 4.1.1p4

comment:34 Changed 21 months ago by jdemeyer

This version compiles, but leads to doctest failures, in particular

sage -t src/sage/rings/quotient_ring.py
**********************************************************************
File "src/sage/rings/quotient_ring.py", line 89, in sage.rings.quotient_ring
Failed example:
    Q3 = F.quo(F*[F.prod(m) for m in product(F.gens(), repeat=3)]*F)
Exception raised:
    Traceback (most recent call last):
      File "/usr/local/src/sage-config/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 671, in _run
        self.compile_and_execute(example, compiler, test.globs)
      File "/usr/local/src/sage-config/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 1086, in compile_and_execute
        exec(compiled, globs)
      File "<doctest sage.rings.quotient_ring[20]>", line 1, in <module>
        Q3 = F.quo(F*[F.prod(m) for m in product(F.gens(), repeat=Integer(3))]*F)
      File "/usr/local/src/sage-config/local/lib/python2.7/site-packages/sage/categories/monoids.py", line 158, in prod
        return prod(args, self.one())
      File "sage/misc/misc_c.pyx", line 144, in sage.misc.misc_c.prod (build/cythonized/sage/misc/misc_c.c:2570)
        prod = balanced_list_prod(x, 0, n, recursion_cutoff)
      File "sage/misc/misc_c.pyx", line 180, in sage.misc.misc_c.balanced_list_prod (build/cythonized/sage/misc/misc_c.c:2706)
        prod *= <object>PySequence_Fast_GET_ITEM(L, k)
      File "sage/structure/element.pyx", line 1517, in sage.structure.element.Element.__mul__ (build/cythonized/sage/structure/element.c:12023)
        return (<Element>left)._mul_(right)
      File "sage/algebras/letterplace/free_algebra_element_letterplace.pyx", line 604, in sage.algebras.letterplace.free_algebra_element_letterplace.FreeAlgebraElement_letterplace._mul_ (build/cythonized/sage/algebras/letterplace/free_algebra_element_letterplace.cpp:9525)
        rshift = singular_system("stest",right._poly,left._poly.degree(),A._degbound,A.__ngens, ring=A._current_ring)
      File "sage/libs/singular/function.pyx", line 1330, in sage.libs.singular.function.SingularFunction.__call__ (build/cythonized/sage/libs/singular/function.cpp:15057)
        return call_function(self, args, ring, interruptible, attributes)
      File "sage/libs/singular/function.pyx", line 1528, in sage.libs.singular.function.call_function (build/cythonized/sage/libs/singular/function.cpp:17033)
        raise RuntimeError("error in Singular function call %r:\n%s" %
    RuntimeError: error in Singular function call 'system':
    wrong length of parameters(4), expected `poly`,`int`
**********************************************************************

comment:35 Changed 21 months ago by arojas

Yes, see comment:25. The letterplace algebra implementation has been completely rewritten in Singular, in particular "stest" can only be used with rings that are explicitely declared as letterplace. In the long term free_algebra_letterplace.pyx should be refactored to use the new implementation, but a faster short-term solution could be to implement an internal variable shifting method in Sage itself (to replace "stest" usage).

comment:36 Changed 20 months ago by slelievre

  • Cc slelievre added
  • Keywords upgrade Singular added

It seems Singular 4-1-2 is out, see the GitHub "releases" page and one official sources directory at uni-kl:

So far no mention on the Singular home page or download page:

but I guess they will be updated soon.

comment:37 follow-up: Changed 20 months ago by arojas

Relevant changes: system("stest") and system("freegb") are no longer a thing. There is a stest function now, but it's marked static so not accessible from outside the library.

comment:38 in reply to: ↑ 37 ; follow-up: Changed 20 months ago by SimonKing

Replying to arojas:

Relevant changes: system("stest") and system("freegb") are no longer a thing. There is a stest function now, but it's marked static so not accessible from outside the library.

That's quite unfortunate. freegb is needed for free commutative algebras in letterplace implementation. I am not sure if stest is needed there, too.

Any replacement for freegb?

comment:39 in reply to: ↑ 38 ; follow-up: Changed 20 months ago by arojas

Replying to SimonKing:

Replying to arojas:

Relevant changes: system("stest") and system("freegb") are no longer a thing. There is a stest function now, but it's marked static so not accessible from outside the library.

That's quite unfortunate. freegb is needed for free commutative algebras in letterplace implementation. I am not sure if stest is needed there, too.

Any replacement for freegb?

Looks like one can simply use std now https://github.com/Singular/Sources/commit/6a0ad754

Last edited 20 months ago by arojas (previous) (diff)

comment:40 Changed 20 months ago by jdemeyer

  • Description modified (diff)
  • Summary changed from Upgrade to Singular 4.1.1p4 to Upgrade Singular

comment:41 Changed 16 months ago by isuruf

  • Cc isuruf saraedum added

comment:42 in reply to: ↑ 39 Changed 10 months ago by gh-mwageringel

Replying to arojas:

Looks like one can simply use std now https://github.com/Singular/Sources/commit/6a0ad754

Indeed, std/twostd can be used for this, but one needs to work over a polynomial ring constructed via `freeAlgebra`, so that certain attributes like the degree bound are set for the computation.

However, I do not see how to make the degrees option work, as Singular's freeAlgebra function does not allow for block orders:

sage: F.<a,b,c> = FreeAlgebra(QQ, implementation='letterplace', degrees=(1,2,3))
sage: F.commutative_ring().term_order()
Block term order with blocks:
(Degree reverse lexicographic term order of length 3,
 Lexicographic term order of length 1)

sage: from sage.libs.singular.function_factory import ff
sage: A = ff.freegb__lib.freeAlgebra(F.commutative_ring(), 5)
...
RuntimeError: error in Singular function call 'freeAlgebra':
only for rings with a global ordering of one block

This is with Singular 4.1.2p1 (freeAlgebra does not exist in the Singular version that is currently in Sage).

The other failing doctests seem mostly harmless.

comment:43 follow-ups: Changed 10 months ago by gh-mwageringel

  • Description modified (diff)
  • Milestone changed from sage-8.5 to sage-9.1

With Singular 4.1.2p2, building Pynac fails with errors like this:

In file included from /amd/compute/mwagerin/git/sage_compute/python3/local/include/factory/factory.h:26,
                 from mpoly-singular.cpp:27:
/amd/compute/mwagerin/git/sage_compute/python3/local/include/factory/factoryconf.h:21:10: fatal error: factory/globaldefs.h: No such file or directory
 #include "factory/globaldefs.h"
          ^~~~~~~~~~~~~~~~~~~~~~

I do not know how to resolve this.

comment:44 in reply to: ↑ 43 Changed 10 months ago by fbissey

Replying to gh-mwageringel:

With Singular 4.1.2p2, building Pynac fails with errors like this:

In file included from /amd/compute/mwagerin/git/sage_compute/python3/local/include/factory/factory.h:26,
                 from mpoly-singular.cpp:27:
/amd/compute/mwagerin/git/sage_compute/python3/local/include/factory/factoryconf.h:21:10: fatal error: factory/globaldefs.h: No such file or directory
 #include "factory/globaldefs.h"
          ^~~~~~~~~~~~~~~~~~~~~~

I do not know how to resolve this.

Does the file exists? If not it looks like a bug in singular's installation. I'll have a look locally when I can.

comment:45 in reply to: ↑ 43 ; follow-up: Changed 10 months ago by arojas

Replying to gh-mwageringel:

With Singular 4.1.2p2, building Pynac fails with errors like this:

In file included from /amd/compute/mwagerin/git/sage_compute/python3/local/include/factory/factory.h:26,
                 from mpoly-singular.cpp:27:
/amd/compute/mwagerin/git/sage_compute/python3/local/include/factory/factoryconf.h:21:10: fatal error: factory/globaldefs.h: No such file or directory
 #include "factory/globaldefs.h"
          ^~~~~~~~~~~~~~~~~~~~~~

I do not know how to resolve this.

This is a bug in singular install: https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/singular#n42

comment:46 follow-up: Changed 10 months ago by fbissey

Did you fill a ticket upstream?

comment:47 in reply to: ↑ 46 ; follow-up: Changed 10 months ago by arojas

Replying to fbissey:

Did you fill a ticket upstream?

No - i'm tired of filing singular bug reports just to have them ignored.

comment:48 in reply to: ↑ 45 Changed 10 months ago by gh-mwageringel

Replying to arojas:

This is a bug in singular install: https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/singular#n42

Thank you. That works.

comment:49 in reply to: ↑ 47 ; follow-up: Changed 10 months ago by arojas

Replying to arojas:

Replying to fbissey:

Did you fill a ticket upstream?

No - i'm tired of filing singular bug reports just to have them ignored.

Seems to be fixed in git master

comment:50 in reply to: ↑ 49 ; follow-up: Changed 10 months ago by fbissey

Replying to arojas:

Replying to arojas:

Replying to fbissey:

Did you fill a ticket upstream?

No - i'm tired of filing singular bug reports just to have them ignored.

Seems to be fixed in git master

If you are thinking of https://github.com/Singular/Sources/commit/557b878dd8c840afb5ec95de122ba27a0ec99926 it is in my source for 4.1.2p2 and it obviously doesn't help. Are you thinking of another commit?

comment:51 in reply to: ↑ 50 Changed 10 months ago by arojas

Replying to fbissey:

Replying to arojas:

Replying to arojas:

Replying to fbissey:

Did you fill a ticket upstream?

No - i'm tired of filing singular bug reports just to have them ignored.

Seems to be fixed in git master

If you are thinking of https://github.com/Singular/Sources/commit/557b878dd8c840afb5ec95de122ba27a0ec99926 it is in my source for 4.1.2p2 and it obviously doesn't help. Are you thinking of another commit?

I don't know which commit fixed it, I just compiled git master and checked that the header is installed.

comment:52 Changed 10 months ago by fbissey

All right it is actually fixed in the next commit https://github.com/Singular/Sources/commit/10ccdf4ec3a17fc1e6b47d06f9abf4565ae63341

kind of sad.

comment:53 Changed 10 months ago by fbissey

I have checked, that commit is all you need to get this particular header.

comment:54 follow-up: Changed 10 months ago by gh-mwageringel

  • Work issues set to update letterplace algebras

Regarding the degrees option of letterplace algebras, Singular should support weighted degree orders naturally now, so Sage's workaround using slack variables should not be necessary anymore. However, I have difficulties to reproduce the old results with Singular's new implementation. The example from letterplace.pyx:

sage: F.<x,y,z> = FreeAlgebra(QQ, implementation='letterplace', degrees=[1,2,3])
sage: I = F * [x*y+z-y*x, x*y*z-x^6+y^3] * F
sage: I.groebner_basis(Infinity)
...
sage: F.degbound()
22

The maximum degree was 22, so the following Singular code should compute the same, as far as I understand, but it fails with an error:

LIB "freegb.lib";
ring r = 0,(x,y,z),wp(1,2,3);
def R = freeAlgebra(r, 22);
setring R;
ideal I = x*y+z-y*x, x*y*z-x^6+y^3;
ideal J = twostd(I);
//   ? degree bound of Letterplace ring is 22, but at least 23 is needed for this multiplication

Is this a bug in Singular? I think Singular should make sure not to go beyond the degree bound in this computation.

comment:55 in reply to: ↑ 54 Changed 9 months ago by gh-mwageringel

I have posted this problem to the Singular forums.

comment:56 Changed 9 months ago by gh-mwageringel

  • Branch changed from u/jdemeyer/ticket/25993 to u/gh-mwageringel/singular412p1
  • Commit changed from 4bd32fe685b58802a56a8a6cb4e75b9abe02e94b to 0c071234ae99343c40735b17280cdf5d0b3a2d6d
  • Work issues changed from update letterplace algebras to segfault in plural.pyx

Viktor Levandovskyy has sent a response to the problem, which was very helpful. The ordering I was trying to use is not actually supported. Also, some of the orderings Sage was using in the letterplace computations were not actually supported and, apparently, were silently ignored by Singular. As a consequence, results obtained with the new Letterplace API (which now supports some of the orders) may be a bit different than before. In the case of non-standard degrees, a deglex ordering seems to give similar results as before.

Here is a tentative branch that makes Sage's letterplace functionality work with Singular 4.1.2p1. I followed Antonio's suggestion from comment:35 and his downstream patch about implementing a variable shifting method, and implemented a workaround to call Singular's twostd with a letterplace polynomial ring constructed via freeAlgebra. Of course, this should only be seen as a short-term solution, to maintain backward compatibility where possible.


There is one remaining problem for upgrading to Singular 4.1.2p1. The tests in src/sage/rings/polynomial/plural.pyx sometimes produce the segmentation fault reported in comment:22, which I do not know how to resolve. For me, the segfault usually occurs during make ptestlong, but not always when testing the file standalone.

Any help with this is appreciated.


New commits:

0ff739025993: upgrade to singular 4.1.2p1
71c871f25993: rename polynomial shift method to _cycle
0c0712325993: call new Singular API for letterplace algebras

comment:57 Changed 8 months ago by arojas

Good news, the plural.pyx segfault seems fixed in 4.1.2.p3. There are a few additional test failures, but they look mostly harmless, caused by doc output changes and different generators for some ideals. There's also a small regression in the pc file https://www.singular.uni-kl.de:8005/trac/ticket/861

comment:58 Changed 8 months ago by fbissey

fails its own testsuite on gentoo for stupid reason

make  check-TESTS
make[4]: Entering directory '/dev/shm/portage/sci-mathematics/singular-4.1.2_p3/work/singular-4.1.2/libpolys/polys'
make[5]: Entering directory '/dev/shm/portage/sci-mathematics/singular-4.1.2_p3/work/singular-4.1.2/libpolys/polys'
../../build-aux/test-driver: line 107: 707661 Segmentation fault      (core dumped) "$@" > $log_file 2>&1
FAIL: test
============================================================================
Testsuite summary for libpolys 4.1.2
============================================================================
# TOTAL: 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0
============================================================================
See polys/test-suite.log

And when I look at the core dump

#0  0x00007f272947b23a in p_Add_q__FieldGeneral_LengthOne_OrdPomog () from /usr/libexec/singular/MOD/p_Procs_FieldGeneral.so
#1  0x00005583ef7743b8 in TestSum(ip_sring*, int) ()
#2  0x00005583ef775c03 in Test(ip_sring*) ()
#3  0x00005583ef77618f in test_Z13_t_GF() ()
#4  0x00005583ef77236f in main ()

the stupid thing tries to load a plugin from a previous install rather than the one it just compiled.

Tests pass on a machine with singular removed but it is annoying.

comment:59 Changed 8 months ago by arojas

4.1.2p4 has just been released with a fix for the pkgconfig issue

comment:60 Changed 8 months ago by fbissey

My test suite issue is now https://github.com/Singular/Sources/issues/980 but if everything else can be worked out we should proceed. I'll add that flint detection is stinky and poorly thought out. It kinds of works but leads to messy warnings in the linker in some systems.

comment:61 Changed 8 months ago by gh-mwageringel

  • Branch changed from u/gh-mwageringel/singular412p1 to u/gh-mwageringel/singular412p4
  • Commit changed from 0c071234ae99343c40735b17280cdf5d0b3a2d6d to 9dbc2badedcda7046e37bc5adc2a4768f60318e6
  • Description modified (diff)
  • Work issues segfault in plural.pyx deleted

I have updated the branch to fix the doctests for Singular 4.1.2p4. The changes are mostly harmless:

  • sign changes in the representatives of fraction field elements
  • rational points are returned in a different order
  • intersection of ideals does not return a Gröbner basis anymore: Neither Sage nor Singular clearly state that the result should be a Gröbner basis, so this change seems fine, but it might be worth checking whether this change was intentional.

New commits:

3af226fMerge tag '9.1.beta4' into #25993
9dbc2ba25993: upgrade to singular 4.1.2p4

comment:62 Changed 8 months ago by gh-mwageringel

  • Cc dkrenn araichev cheuberg behackl added
  • Work issues set to failing doctests in asymptotics_multivariate_generating_functions.py

The only remaining failing doctests are in asymptotics_multivariate_generating_functions.py. It would be nice if the authors or anyone familiar with asymptotics could take a look.

Some of these are caused by different representatives being chosen modulo an ideal, which should be fine. However, the relative error does not get small anymore which suggests that there might be a bug on the Sage side.

File "src/sage/rings/asymptotic/asymptotics_multivariate_generating_functions.py", line 1576, in sage.rings.asymptotic.asymptotics_multivariate_generating_functions.FractionWithFactoredDenominator.?
Failed example:
    decomp = F.asymptotic_decomposition(alpha); decomp
Expected:
    (0, []) + (-3/2*r*(1/y + 1) - 1/2/y - 1/2, [(x*y + x + y - 1, 1)])
Got:
    (0, []) + (2*r*(1/x + 1) + 1/2/x - 1/2, [(x*y + x + y - 1, 1)])
**********************************************************************
File "src/sage/rings/asymptotic/asymptotics_multivariate_generating_functions.py", line 1585, in sage.rings.asymptotic.asymptotics_multivariate_generating_functions.FractionWithFactoredDenominator.?
Failed example:
    asy
Expected:
    (1/6000*(3600*sqrt(5)*sqrt(3)*sqrt(2)*sqrt(r)/sqrt(pi)
      + 463*sqrt(5)*sqrt(3)*sqrt(2)/(sqrt(pi)*sqrt(r)))*432^r,
     432,
     3/5*sqrt(5)*sqrt(3)*sqrt(2)*sqrt(r)/sqrt(pi)
      + 463/6000*sqrt(5)*sqrt(3)*sqrt(2)/(sqrt(pi)*sqrt(r)))
Got:
    (-1/6000*(3600*sqrt(5)*sqrt(3)*sqrt(2)*sqrt(r)/sqrt(pi) - 137*sqrt(5)*sqrt(3)*sqrt(2)/(sqrt(pi)*sqrt(r)))*432^r,
     432,
     -3/5*sqrt(5)*sqrt(3)*sqrt(2)*sqrt(r)/sqrt(pi) + 137/6000*sqrt(5)*sqrt(3)*sqrt(2)/(sqrt(pi)*sqrt(r)))
**********************************************************************
File "src/sage/rings/asymptotic/asymptotics_multivariate_generating_functions.py", line 1591, in sage.rings.asymptotic.asymptotics_multivariate_generating_functions.FractionWithFactoredDenominator.?
Failed example:
    F.relative_error(asy[0], alpha, [1, 2, 4, 8, 16], asy[1])  # abs tol 1e-10
Expected:
    [((4, 3), 2.083333333, [2.092576110], [-0.004436533009]),
     ((8, 6), 2.787374614, [2.790732875], [-0.001204811281]),
     ((16, 12), 3.826259447, [3.827462310], [-0.0003143703383]),
     ((32, 24), 5.328112821, [5.328540787], [-0.00008032230388]),
     ((64, 48), 7.475927885, [7.476079664], [-0.00002030232879])]
Got:
    [((4, 3), 2.083333333, [-1.783556749], [1.856107239]),
     ((8, 6), 2.787374614, [-2.572223188], [1.922812160]),
     ((16, 12), 3.826259447, [-3.672952629], [1.959932979]),
     ((32, 24), 5.328112821, [-5.219285944], [1.979574968]),
     ((64, 48), 7.475927885, [-7.398824824], [1.989686489])]
Tolerance exceeded in 10 of 25:
    2.092576110 vs -1.783556749, tolerance 4e0 > 1e-10
    -0.004436533009 vs 1.856107239, tolerance 2e0 > 1e-10
    2.790732875 vs -2.572223188, tolerance 6e0 > 1e-10
    -0.001204811281 vs 1.922812160, tolerance 2e0 > 1e-10
    3.827462310 vs -3.672952629, tolerance 8e0 > 1e-10
    -0.0003143703383 vs 1.959932979, tolerance 2e0 > 1e-10
    5.328540787 vs -5.219285944, tolerance 2e1 > 1e-10
    -0.00008032230388 vs 1.979574968, tolerance 2e0 > 1e-10
    7.476079664 vs -7.398824824, tolerance 2e1 > 1e-10
    -0.00002030232879 vs 1.989686489, tolerance 2e0 > 1e-10
**********************************************************************
File "src/sage/rings/asymptotic/asymptotics_multivariate_generating_functions.py", line 1609, in sage.rings.asymptotic.asymptotics_multivariate_generating_functions.FractionWithFactoredDenominator.?
Failed example:
    decomp = F.asymptotic_decomposition(alpha); decomp
Expected:
    (0, []) +
    (-16*r*(3/y - 4/z) - 16/y + 32/z,
     [(x + 2*y + z - 4, 1), (2*x + y + z - 4, 1)])
Got:
    (0, []) + (-16*r*(3/x - 2/z) - 16/x + 16/z, [(x + 2*y + z - 4, 1), (2*x + y + z - 4, 1)])
**********************************************************************
File "src/sage/rings/asymptotic/asymptotics_multivariate_generating_functions.py", line 1620, in sage.rings.asymptotic.asymptotics_multivariate_generating_functions.FractionWithFactoredDenominator.?
Failed example:
    asy # long time
Expected:
    (4/3*sqrt(3)*sqrt(r)/sqrt(pi) + 47/216*sqrt(3)/(sqrt(pi)*sqrt(r)),
     1, 4/3*sqrt(3)*sqrt(r)/sqrt(pi) + 47/216*sqrt(3)/(sqrt(pi)*sqrt(r)))
Got:
    (-4/3*sqrt(3)*sqrt(r)/sqrt(pi) - 47/216*sqrt(3)/(sqrt(pi)*sqrt(r)),
     1,
     -4/3*sqrt(3)*sqrt(r)/sqrt(pi) - 47/216*sqrt(3)/(sqrt(pi)*sqrt(r)))
**********************************************************************
File "src/sage/rings/asymptotic/asymptotics_multivariate_generating_functions.py", line 1623, in sage.rings.asymptotic.asymptotics_multivariate_generating_functions.FractionWithFactoredDenominator.?
Failed example:
    F.relative_error(asy[0], alpha, [1, 2, 4, 8], asy[1]) # long time
Expected:
    [((3, 3, 2), 0.9812164307, [1.515572606], [-0.54458543...]),
     ((6, 6, 4), 1.576181132, [1.992989399], [-0.26444185...]),
     ((12, 12, 8), 2.485286378, [2.712196351], [-0.091301338...]),
     ((24, 24, 16), 3.700576827, [3.760447895], [-0.016178847...])]
Got:
    [((3, 3, 2), 0.9812164307, [-1.515572606], [2.544585434]),
     ((6, 6, 4), 1.576181132, [-1.992989399], [2.264441858]),
     ((12, 12, 8), 2.485286378, [-2.712196351], [2.091301338]),
     ((24, 24, 16), 3.700576827, [-3.760447895], [2.016178847])]
**********************************************************************

comment:63 follow-up: Changed 8 months ago by arojas

Looks like #29247 has broken things again. Getting many failures in sage/algebras/letterplace with this branch on top of 9.1.beta7

comment:64 in reply to: ↑ 63 Changed 7 months ago by gh-mwageringel

  • Dependencies set to #29311

Replying to arojas:

Looks like #29247 has broken things again. Getting many failures in sage/algebras/letterplace with this branch on top of 9.1.beta7

This will be solved by #29311.

comment:65 Changed 7 months ago by mkoeppe

Related to this upgrade ticket: #29335, #29339, #27764

comment:66 Changed 7 months ago by mkoeppe

  • Cc dimpase added

comment:67 follow-up: Changed 7 months ago by mkoeppe

Is this ticket going to be ready for 9.1? Otherwise, we may need a ticket for 9.1 with some portability fixes (see #29415)

comment:68 in reply to: ↑ 67 Changed 7 months ago by gh-mwageringel

  • Milestone changed from sage-9.1 to sage-9.2

Replying to mkoeppe:

Is this ticket going to be ready for 9.1?

Probably not. There are still failing doctests related to asymptotics. Someone should look into that.

But even then, it might be better to merge this in the next release cycle in order to give it some time to get tested.

comment:69 Changed 7 months ago by git

  • Commit changed from 9dbc2badedcda7046e37bc5adc2a4768f60318e6 to 78f439e57fe3cceb59f7850cde7aa56692351099

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

5692f8b29465: fix sign error in cohomology_decomposition of asymptotics
2a09d15Merge branch #29465 into #25993
bdf81be25993: update doctests in asymptotics for Singular 4.1.2p4
78f439e25993: add upstream_url for singular

comment:70 Changed 7 months ago by gh-mwageringel

  • Authors set to Antonio Rojas, Markus Wageringel
  • Dependencies changed from #29311 to #29465
  • Status changed from new to needs_review
  • Work issues failing doctests in asymptotics_multivariate_generating_functions.py deleted

I found the problem in the asymptotics code. It is caused by an incorrect sign and is resolved by #29465, needing review.

Now this makes all the doctests pass with Singular 4.1.2p4, so this is ready for testing. The optional packages in particular still need to be tested.

Meanwhile, Singular 4.1.2p5 has been released and produces many segmentation faults all over the place, so I guess we stick to 4.1.2p4 for now.

comment:71 Changed 7 months ago by arojas

The segfaults are fixed with https://github.com/Singular/Sources/commit/7886c15a361119b200bd15faef4bf5b620d783ad

4.1.3 is out with just one additional, harmless test failure

diff --git a/src/sage/libs/singular/function.pyx b/src/sage/libs/singular/function.pyx
index b649ab1e64..72f34fd67d 100644
--- a/src/sage/libs/singular/function.pyx
+++ b/src/sage/libs/singular/function.pyx
@@ -1308,7 +1308,7 @@ cdef class SingularFunction(SageObject):
             ...
             RuntimeError: error in Singular function call 'triangL':
             The input is no groebner basis.
-            leaving triang.lib::triangL
+            leaving triang.lib::triangL (0)
 
         Flush any stray output -- see :trac:`28622`::
 

comment:72 Changed 7 months ago by gh-mwageringel

  • Branch changed from u/gh-mwageringel/singular412p4 to public/singular4-1-3
  • Commit changed from 78f439e57fe3cceb59f7850cde7aa56692351099 to 8722c0f11e1567dd4598bee604511208ad7f847d
  • Description modified (diff)

Thanks for the note. I have updated the branch.


New commits:

8722c0f25993: upgrade to singular 4.1.3

comment:73 Changed 6 months ago by git

  • Commit changed from 8722c0f11e1567dd4598bee604511208ad7f847d to 5e496abfe428e9ea37db55a8f3a94dc3a462cfa2

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

775f92325993: Merge tag '9.1.rc0' into #25993
5e496ab25993: remove patch "Fix building singular with -DNDEBUG"

comment:74 follow-ups: Changed 6 months ago by gh-mwageringel

I have merged 9.1.rc0 and removed the (backported) patch from #29438.

With this, I get the segmentation fault in plural.pyx from comment:22 again. I am not sure what to do with this. Maybe we could mark it as not tested and open a new ticket for it.

comment:75 in reply to: ↑ 74 Changed 6 months ago by dimpase

Replying to gh-mwageringel:

I have merged 9.1.rc0 and removed the (backported) patch from #29438.

With this, I get the segmentation fault in plural.pyx from comment:22 again. I am not sure what to do with this. Maybe we could mark it as not tested and open a new ticket for it.

+1

comment:76 in reply to: ↑ 74 ; follow-up: Changed 6 months ago by soehms

Replying to gh-mwageringel:

I have merged 9.1.rc0 and removed the (backported) patch from #29438.

With this, I get the segmentation fault in plural.pyx from comment:22 again.

I can't reproduce that.

I checked out the ticket on top of 9.1.rc0 and run make according to the ticket description but all tests of src/sage/rings/polynomial/plural.pyx passed.

Did I miss something? I did that under Windows10 (WSL Ubuntu). The make log-messages said that Singular 4.1.3 had been build but if I start Singular (through Sage) I get:

                     SINGULAR                                 /  Development
 A Computer Algebra System for Polynomial Computations       /   version 4.1.2
                                                           0<
 by: W. Decker, G.-M. Greuel, G. Pfister, H. Schoenemann     \   Mar 2020
FB Mathematik der Universitaet, D-67653 Kaiserslautern        \

comment:77 in reply to: ↑ 76 ; follow-up: Changed 6 months ago by gh-mwageringel

Replying to soehms:

I can't reproduce that.

I checked out the ticket on top of 9.1.rc0 and run make according to the ticket description but all tests of src/sage/rings/polynomial/plural.pyx passed.

Thanks for taking a look. There is some randomness to this bug. With the current branch, it consistently occurs for me, but has been appearing only from time to time while working on this ticket. If I copy the offending doctest to the top of the file to better isolate the problem, it disappears. I am not even sure if it is really caused by this upgrade – the underlying problem might already exist in Sage without being noticed.

The make log-messages said that Singular 4.1.3 had been build but if I start Singular (through Sage) I get:

                     SINGULAR                                 /  Development
 A Computer Algebra System for Polynomial Computations       /   version 4.1.2
                                                           0<
 by: W. Decker, G.-M. Greuel, G. Pfister, H. Schoenemann     \   Mar 2020
FB Mathematik der Universitaet, D-67653 Kaiserslautern        \

Yes, I get that as well. Apparently upstream forgot to change that version number.

comment:78 in reply to: ↑ 77 ; follow-up: Changed 6 months ago by soehms

Replying to gh-mwageringel:

Replying to soehms: There is some randomness to this bug.

That's not good looking!

I tried to reproduce it on another machine (running under Linux Mint 19.1 and Sage with Python 2) but without success, again.

If I copy the offending doctest to the top of the file to better isolate the problem, it disappears.

Does it disappear if you let it in on its position but supress some of the previous doctests, as well?

In my experience such segmentation faults are mostly caused by a previous call of some C-function with no prototype and a wrong number of arguments or some usage of a non initialized variable. Anyway, I think this bug will be very difficult to find!

comment:79 Changed 6 months ago by dimpase

This looks to me as one of these testing framework Heisenbugs we see elsewhere, as well.

comment:80 Changed 6 months ago by git

  • Commit changed from 5e496abfe428e9ea37db55a8f3a94dc3a462cfa2 to 827aa6c8a1d99bd50de6d431085c77164d3a39bb

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

827aa6c25993: disable problematic doctest in plural.pyx

comment:81 in reply to: ↑ 78 ; follow-up: Changed 6 months ago by gh-mwageringel

Replying to soehms:

Does it disappear if you let it in on its position but supress some of the previous doctests, as well?

Yes, if I remove the previous block of tests from the previous method, it disappears, too. Even if I move that block of tests from the previous method to the affected method, and thus preserve all tests and their order, everything works fine. Heisenbug indeed. As you cannot replicate it, this problem might not be too serious. Thanks for looking into it, though.

I have disabled the test on the current branch and opened #29528 for it.

comment:82 in reply to: ↑ 81 Changed 6 months ago by soehms

Replying to gh-mwageringel:

Replying to soehms:

Does it disappear if you let it in on its position but supress some of the previous doctests, as well?

Yes, if I remove the previous block of tests from the previous method, it disappears, too. Even if I move that block of tests from the previous method to the affected method, and thus preserve all tests and their order, everything works fine. Heisenbug indeed. As you cannot replicate it, this problem might not be too serious.

Now, I tried again using the doctest option --global-iterations. With this I was able to reproduce all of your observations (repeatable after 9 loops in the WSL case and 11 loops in the Linux Mint case).

On the other hand, on a 9.1.rc0 installation without that Singular upgrade the segmentation fault didn't occur until loop 500.

comment:83 follow-up: Changed 6 months ago by gh-mwageringel

This is just a guess, but this might be related to the problem that the NCPolynomial_plural elements are sometimes not properly deallocated because the parent ring is not defined anymore, for some reason. Indeed, this change produces a warning in exactly the doctest in __reduce__ which preceeds the problematic one.

  • src/sage/rings/polynomial/plural.pyx

    a b cdef class NCPolynomial_plural(RingElement): 
    14311431    def __dealloc__(self):
    14321432        # TODO: Warn otherwise!
    14331433        # for some mysterious reason, various things may be NULL in some cases
    14341434        if self._parent is not None and (<NCPolynomialRing_plural>self._parent)._ring != NULL and self._poly != NULL:
    14351435            p_Delete(&self._poly, (<NCPolynomialRing_plural>self._parent)._ring)
     1436        elif self._poly != NULL:
     1437            print("warning in NCPolynomial_plural.__dealloc__")
    14361438
    14371439    def __reduce__(self):
    14381440        """
    14391441        TESTS::

comment:84 in reply to: ↑ 83 Changed 6 months ago by SimonKing

Replying to gh-mwageringel:

This is just a guess, but this might be related to the problem that the NCPolynomial_plural elements are sometimes not properly deallocated because the parent ring is not defined anymore, for some reason.

There was #13447 dedicated to having proper refcount for libsingular rings. If I recall correctly, the problem is that refcounting in Singular ONLY happens for rings in the interface, i.e. there is no refcount when polynomials are created. However, there is an internal ref counter in Singular that sometimes in very few places in the Singular code is used.

Anyway, perhaps it makes sense to revive that other ticket and finally try and get the refcount problem done.

comment:85 follow-up: Changed 6 months ago by arojas

9.1.rc2 introduces one new test failure:

File "/usr/lib/python3.8/site-packages/sage/rings/polynomial/multi_polynomial_ideal.py", line 3969, in sage.rings.polynomial.multi_polynomial_ideal.NCPolynomialIdeal.groebner_basis
Failed example:
    ideal(J.transformed_basis()).change_ring(P).interreduced_basis()  # testing trac 21884
Expected:
    [a - 60*c^3 + 158/7*c^2 + 8/7*c - 1, b + 30*c^3 - 79/7*c^2 + 3/7*c, c^4 - 10/21*c^3 + 1/84*c^2 + 1/84*c]
Got:
    // ** redefining xR (   keepring basering;)
    [a - 60*c^3 + 158/7*c^2 + 8/7*c - 1, b + 30*c^3 - 79/7*c^2 + 3/7*c, c^4 - 10/21*c^3 + 1/84*c^2 + 1/84*c]

comment:86 Changed 5 months ago by git

  • Commit changed from 827aa6c8a1d99bd50de6d431085c77164d3a39bb to 6f57ea5d63f4f1886f039dec900e48bf1acc880d

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

4199b0c25993: Merge tag '9.2.beta0' into #25993
5e6a38325993: fix ntl patch
301a55425993: fix doctest with flaky singular pexpect output
6f57ea525993: replace _cycle by permutation action on polynomials

comment:87 in reply to: ↑ 85 Changed 5 months ago by gh-mwageringel

  • Dependencies #29465 deleted
  • Priority changed from major to critical

Replying to arojas:

9.1.rc2 introduces one new test failure:

This is some side-effect in the Singular pexpect interface that appears since #29543 and seems to be harmless. I have updated the doctest.

I have also removed the shift/_cycle method, as it can be replaced by the action of permutations on polynomials.

This ticket is now ready for review. It would be nice to get this merged into one of the next betas.

comment:88 Changed 5 months ago by fbissey

Should we try for 4.1.3_p2 instead of 4.1.3? Or _p3 if it has been released since the last time I looked.

comment:89 Changed 5 months ago by gh-mwageringel

Well, this is a moving target. I can try it tomorrow and, if it does not break anything, I guess it would not hurt to include it. Otherwise, it probably does not make this ticket simpler, so could also be done on a new ticket.

comment:90 Changed 5 months ago by fbissey

That's a good plan.

comment:91 Changed 5 months ago by arojas

Anything more recent than 4.1.3 has a bug that makes the test suite hang in schemes/curves/affine_curve.py

http://www.singular.uni-kl.de:8002/trac/ticket/865

comment:92 Changed 5 months ago by fbissey

You say 4.1.2p1 in that ticket. Was that meant to be 4.1.3p1?

comment:93 Changed 5 months ago by arojas

Yes, there's no way to modify a ticket if you file it without an account

comment:94 follow-up: Changed 5 months ago by arojas

Besides the hang, with singular>=4.1.3p1 there are two more trivial test failures due to changes in ring notation display. Perhaps these could be fixed here so they pass on distros that ship a newer singular

**********************************************************************
File "/usr/lib/python3.8/site-packages/sage/rings/polynomial/polynomial_singular_interface.py", line 166, in sage.rings.polynomial.polynomial_singular_interface.PolynomialRing_singular_repr._singular_
Failed example:
    singular(R)
Expected:
    polynomial ring, over a ring (with zero-divisors), global ordering
    //   coefficients: ZZ/bigint(15)
    //   number of vars : 2
    //        block   1 : ordering dp
    //                  : names    x y
    //        block   2 : ordering C
Got:
    polynomial ring, over a ring (with zero-divisors), global ordering
    // coefficients: ZZ/(15)
    // number of vars : 2
    //        block   1 : ordering dp
    //                  : names    x y
    //        block   2 : ordering C
**********************************************************************
File "/usr/lib/python3.8/site-packages/sage/rings/polynomial/multi_polynomial_libsingular.pyx", line 1349, in sage.rings.polynomial.multi_polynomial_libsingular.MPolynomialRing_libsingular._singular_init_
Failed example:
    singular(R)
Expected:
    polynomial ring, over a ring (with zero-divisors), global ordering
    //   coefficients: ZZ/bigint(15)
    //   number of vars : 2
    //        block   1 : ordering dp
    //                  : names    x y
    //        block   2 : ordering C
Got:
    polynomial ring, over a ring (with zero-divisors), global ordering
    // coefficients: ZZ/(15)
    // number of vars : 2
    //        block   1 : ordering dp
    //                  : names    x y
    //        block   2 : ordering C
**********************************************************************

comment:95 Changed 5 months ago by git

  • Commit changed from 6f57ea5d63f4f1886f039dec900e48bf1acc880d to edd946ec0bb9eff72d45b112cba027af42b4b8a2

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

edd946e25993: make tests compatible with Singular ≥ 4.1.3p1

comment:96 in reply to: ↑ 94 Changed 5 months ago by gh-mwageringel

Replying to arojas:

Besides the hang, with singular>=4.1.3p1 there are two more trivial test failures due to changes in ring notation display. Perhaps these could be fixed here so they pass on distros that ship a newer singular

Thanks for the infos. I have updated these doctests.

comment:97 follow-up: Changed 4 months ago by mkoeppe

What's missing on this ticket?

comment:99 in reply to: ↑ 97 Changed 4 months ago by gh-mwageringel

Replying to mkoeppe:

What's missing on this ticket?

It just needs a review. The problem in comment:91 appears to be fixed upstream, but the fix is not in 4.1.3p2.

comment:100 Changed 4 months ago by mkoeppe

Then I guess we need a patch on top of 4.1.3p2

comment:101 Changed 4 months ago by mkoeppe

  • Status changed from needs_review to needs_work

comment:102 Changed 4 months ago by mkoeppe

  • Report Upstream changed from N/A to Fixed upstream, but not in a stable release.

comment:103 Changed 4 months ago by git

  • Commit changed from edd946ec0bb9eff72d45b112cba027af42b4b8a2 to 3bc9caa3ac50a7831b32c641574bf66d7773da13

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

3bc9caa25993: add patch fixing hang in primdecSY and upgrade to 4.1.3p2

comment:104 Changed 4 months ago by gh-mwageringel

  • Description modified (diff)
  • Status changed from needs_work to needs_review

I have added the patch.

For some reason, this now requires running make sagelib-clean (otherwise, Sage does not start), so this might break incremental builds. Is there a way around this?

comment:106 Changed 4 months ago by mkoeppe

  • Reviewers set to Matthias Koeppe, ...

Looking good. The failures on homebrew-standard, conda-forge-ubuntu, debian-bullseye-standard, and debian-sid-standard have nothing to do with this ticket.

Other reviewers should comment on the changes on this ticket.

comment:107 follow-up: Changed 4 months ago by mkoeppe

  • Status changed from needs_review to needs_work

However, the builds for cygwin-standard (https://github.com/mkoeppe/sage/runs/839373484) and cygwin-minimal (https://github.com/mkoeppe/sage/runs/839558776) fail.

Unfortunately the detailed logs are not available because an error happened during the log archiving operation.

Last edited 4 months ago by mkoeppe (previous) (diff)

comment:108 Changed 4 months ago by git

  • Commit changed from 3bc9caa3ac50a7831b32c641574bf66d7773da13 to 06e22272a5685c25d922cb55bc06e17e73035780

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

06e2227Merge tag '9.2.beta3' into t/25993/public/singular4-1-3

comment:109 Changed 4 months ago by git

  • Commit changed from 06e22272a5685c25d922cb55bc06e17e73035780 to e0748b6d61ac6e3e48c081c6bcf9822fa4c3cf01

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

e0748b6build/pkgs/singular: Remove python dependency, configure --without-python (singular only supports python2)

comment:110 Changed 4 months ago by mkoeppe

  • Authors changed from Antonio Rojas, Markus Wageringel to Antonio Rojas, Markus Wageringel, Matthias Koeppe

comment:111 Changed 4 months ago by git

  • Commit changed from e0748b6d61ac6e3e48c081c6bcf9822fa4c3cf01 to 4e99a004a58170cd0b9748b16cbd42d0c02f3e2f

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

539c182build/make/install: Do not depend on src/bin/sage-version.sh
761092cMerge branch 't/29987/build_make_install__do_not_depend_on_src_bin_sage_version_sh' into t/30064/fix_tox_docker_builds_broken_by__29884
f2efa6asrc/doc/bootstrap: Create the directory src/doc/en/reference/repl if it does not exist
b7bf43bbuild/bin/write-dockerfile.sh: ADD src/bin for bootstrapping, needed by src/doc/bootstrap after #29884
365ce61Merge branch 'u/mkoeppe/fix_tox_docker_builds_broken_by__29884' of git://trac.sagemath.org/sage into HEAD
1e7becctox.ini [debian-buster, -sid]: IGNORE_MISSING_SYSTEM_PACKAGES=yes because of libpython3.7-dev
fb61a31Merge branch 'u/mkoeppe/tox_ini__debian_bullseye___sid_have_python3_8_instead_of_3_7' of git://trac.sagemath.org/sage into 9.2.beta3+ci-fixes
4e99a00Merge branch '9.2.beta3+ci-fixes' into t/25993/public/singular4-1-3

comment:113 in reply to: ↑ 107 Changed 4 months ago by mkoeppe

  • Report Upstream changed from Fixed upstream, but not in a stable release. to Reported upstream. No feedback yet.

comment:114 Changed 3 months ago by git

  • Commit changed from 4e99a004a58170cd0b9748b16cbd42d0c02f3e2f to 62dfd9aaf7778fb8823a8b6a7f02603b62ca40a5

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

3e991c7build/bin/sage-system-python: Improve check for a suitable python
62dfd9aMerge branch 'u/mkoeppe/build_bin_sage_system_python__improve_check_for_a_suitable_python' of git://trac.sagemath.org/sage into t/25993/public/singular4-1-3

comment:115 Changed 3 months ago by mkoeppe

  • Dependencies set to #30177
  • Report Upstream changed from Reported upstream. No feedback yet. to Reported upstream. Developers acknowledge bug.

Upstream indicates that the Cygwin build problem is fixed https://github.com/Singular/Singular/issues/1017

comment:116 Changed 3 months ago by mkoeppe

... but it's still broken

comment:117 Changed 2 months ago by mkoeppe

  • Milestone changed from sage-9.2 to sage-9.3

comment:118 Changed 5 weeks ago by mkoeppe

  • Dependencies changed from #30177 to #30588

comment:119 Changed 7 days ago by justin

I have seen this problem in the last several releases of 9.2. I get a segmentation fault from singular.py, both with a normal build and running the test just for singular.py.

I followed the instruction at the top in SAGE_ROOT for 9.2.rc2, and the build completed, and the standalone test of singular passed.

The failures have been on 10.14.6 and 10.15.7. No problems at all on 10.13.6.

comment:120 Changed 6 days ago by strogdon

Perhaps not directly related to this ticket but with this ticket I have

sage: sig_on_count() # check sig_on/off pairings (virtual doctest) ## line 499 ##
0
sage: a = singular(1) ## line 511 ##
sage: _ = singular._expect.sendline('1+')  # unfinished input ## line 512 ##
sage: try:
    alarm(0.5)
    singular._expect_expr('>')  # interrupt this
except KeyboardInterrupt:
    pass ## line 513 ##
Control-C pressed. Interrupting Singular. Please wait a few seconds...
sage: 2*a ## line 522 ##
------------------------------------------------------------------------
/local/sage-git/sage/local/lib/python3.8/site-packages/cysignals/signals.cpython-38-x86_64-linux-gnu.so(+0x5a7e)[0x7fad35b98a7e]
/local/sage-git/sage/local/lib/python3.8/site-packages/cysignals/signals.cpython-38-x86_64-linux-gnu.so(+0x5cb0)[0x7fad35b98cb0]
/local/sage-git/sage/local/lib/python3.8/site-packages/cysignals/signals.cpython-38-x86_64-linux-gnu.so(+0x5080)[0x7fad35b98080]
/local/sage-git/sage/local/lib/python3.8/site-packages/cysignals/signals.cpython-38-x86_64-linux-gnu.so(+0x5218)[0x7fad35b98218]
/lib64/libc.so.6(+0x379d0)[0x7fad3eb009d0]

...

Unhandled SIGSEGV: A segmentation fault occurred.
This probably occurred because a *compiled* module has a bug
in it and is not properly wrapped with sig_on(), sig_off().
Python will now terminate.
------------------------------------------------------------------------

**********************************************************************
----------------------------------------------------------------------
sage -t --long --warn-long 214.7 --random-seed=0 src/sage/interfaces/singular.py  # Killed due to segmentation fault

I have seen this with the current (9.2.rc2) singular-4.1.1p2. This is on Gentoo.

Note: See TracTickets for help on using tickets.