-
-
Notifications
You must be signed in to change notification settings - Fork 487
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
update Singular spkg to 4.3.2+ #35676
Comments
I wasn't aware of tht 4.3.2p1 tag, as there is no corresponging tarballs in their server. Do you know if they're planning to release from github from now on, or is it just going to be random? |
Updated downstream, there are no new issues that need fixing in sagelib compared to the current 4.3.1p3 version. The only problem is that they don't provide a source tarball, so it needs to be downloaded from github and docs need to be built from source. Depending on the texinfo version used at build time, this can cause issues when Sage tries to parse the info file. I've opened #35678 to handle this. |
I've asked whether there will be an official source tarball for 4.3.2p1: Singular/Singular#1175 |
@antonio-rojas https://www.singular.uni-kl.de/ftp/pub/Math/Singular/SOURCES/4-3-2/ now contains 4.3.2p1 and p2. |
4.3.2p2 is broken |
After fixing 4.3.2p2 with Singular/Singular@8d54773, I get:
|
I can confirm 4.3.2_p1 does work and do not break any tests here. I probably will not get to play with _p2 if I wait for it in Gentoo main tree. If install is broken we may wait for _p3 or 4.3.3 whichever comes first. |
I tracked the first doctest failure down to sage: R.<x,y> = PolynomialRing(QQ)
sage: J = R.ideal([x, y, x*y + 1])
sage: R.one().lift(J) # with singular 4.3.2p1
[-y, 0, 1]
sage: R.one().lift() # with singular 4.3.2p2
[0, -x, 1] The second doctest failure seems to arise from something similar since the output goes through a Leinartas decomposition at some point. Easy fix: --- a/src/sage/rings/asymptotic/asymptotics_multivariate_generating_functions.py
+++ b/src/sage/rings/asymptotic/asymptotics_multivariate_generating_functions.py
@@ -1251,7 +1251,7 @@ class FractionWithFactoredDenominator(RingElement):
sage: H = R(f.denominator())
sage: ff = FFPD(G, H.factor())
sage: decomp = ff.leinartas_decomposition()
- sage: decomp
+ sage: decomp # random - non canonical depends on singular version
(0, []) +
(-(x*y^2*sin(x) + x^2*y + x*y + y*sin(x) + x)*y, [(y, 1)]) +
((x*y^2*sin(x) + x^2*y + x*y + y*sin(x) + x)*x*y, [(x*y + 1, 1)]) +
@@ -1611,9 +1611,7 @@ class FractionWithFactoredDenominator(RingElement):
(-16, [(x + 2*y + z - 4, 1), (2*x + y + z - 4, 2)])
sage: alpha = [3, 3, 2]
sage: decomp = F.asymptotic_decomposition(alpha); decomp
- (0, []) +
- (16*r*(3/x - 2/z) + 16/x - 16/z,
- [(x + 2*y + z - 4, 1), (2*x + y + z - 4, 1)])
+ (0, []) + (..., [(x + 2*y + z - 4, 1), (2*x + y + z - 4, 1)])
sage: F1 = decomp[1]
sage: p = {x: 1, y: 1, z: 1}
sage: asy = F1.asymptotics(p, alpha, 2, verbose=True) # long time Note that the first test then goes on to check the computed decomposition actually satisfies the definition. And the second test is for |
Really, in the first case since there is a check that the result is correct, we do not need to display and check that output. The fact that it is consistent should be enough. And I do not really think we should display |
On OS X, homebrew's Singular 4.3.2p2 causes several doctest failures — see #35273. Has anyone tested out p1 or building your own p2 on OS X to see if those failures are present? |
Upgrade in #35934 passes these tests on macOS |
4.3.2p3 is out, with one test regression
I don't understand what this test is doing here anyway - it's testing a method from another class which is already tested in its class. Should we just drop it? |
It doesn't belong here, but it's catching some error. Indeed the coefficients for Based on
vs. At least 4.3.2p2 is warning that there was overflow in those coefficients. Indeed the five incorrect coefficients differ by
|
it's insane that coefficients aren't arbitrary precision internally. |
No, the issue is in Singular:
|
Is it reported upstream? In p3 there were some tweaks to |
Note that this has been the case since 4.2.1.p2 - Before, it aborted with an overflow error. From 4.2.1.p2 to 4.3.2.p2 it gave a wrong answer due to overflow. And now it still gives the same wrong answer, but warns about the overflow. I'm not sure this would be considered a bug upstream, given they explicitly changed the code to warn about the overflow (but still return a possibly wrong answer). |
IMHO it should at least error out, not just warn. I expressed my opinion here: Singular/Singular@d1ba061 |
See Singular/Singular#1135 for the issue tracking this example |
Regardless of the upstream report outcome, we need to make it clear that this is giving a wrong answer (and fix the test for singular 4.3.2.p3), done in #35977 |
I found two more regressions in singular 4.3.2p3:
|
Reported at Singular/Singular#1181 |
Fixed, unfortunately by changing the API. The corresponding Sage change is now #35980 |
And opened #36018 to fix test failures in 4.3.2.p4 due to changes in |
Is there an existing issue for this?
Problem Description
currently we ship 4.3.1 with patches, the latest is 4.3.2p1
Experiments indicate that 4.3.2 will need work, though.
Proposed Solution
do the work
Alternatives Considered
n/a
Additional Information
No response
The text was updated successfully, but these errors were encountered: