#25567 closed enhancement (fixed)
Upgrade to pari2.11
Reported by:  jdemeyer  Owned by:  

Priority:  major  Milestone:  sage8.3 
Component:  packages: standard  Keywords:  
Cc:  fbissey, cremona, ghtimokau, frederichan  Merged in:  
Authors:  Jeroen Demeyer  Reviewers:  Timo Kaufmann 
Report Upstream:  Fixed upstream, but not in a stable release.  Work issues:  
Branch:  739f7a6 (Commits, GitHub, GitLab)  Commit:  
Dependencies:  #26010  Stopgaps: 
Description (last modified by )
Attachments (1)
Change History (83)
comment:1 Changed 3 years ago by
 Cc fbissey added
comment:2 Changed 3 years ago by
 Cc cremona added
comment:3 Changed 3 years ago by
 Branch set to u/jdemeyer/upgrade_to_pari_2_10_0_alpha
Changed 3 years ago by
comment:4 followup: ↓ 6 Changed 3 years ago by
 Commit set to 9ed413d71d814afe11255c6e77c319d124a3bec6
See the attached file which crashes using 8.1's pari version. Testing suggests that this will be OK in 2.10.0.alpha, and this should be verified before this ticket is merged.
New commits:
9ed413d  Upgrade to pari2.10.0.alpha

comment:5 Changed 3 years ago by
 Commit changed from 9ed413d71d814afe11255c6e77c319d124a3bec6 to 68662b18cf4f0e5540a0dedddfb3539cacc6ac70
Branch pushed to git repo; I updated commit sha1. New commits:
68662b1  Fix doctests for PARI/GP upgrade

comment:6 in reply to: ↑ 4 ; followup: ↓ 7 Changed 3 years ago by
Replying to cremona:
See the attached file which crashes using 8.1's pari version. Testing suggests that this will be OK in 2.10.0.alpha, and this should be verified before this ticket is merged.
I'm not sure whether you would propose to add it as doctest, but I'd rather not since it takes quite a long time.
comment:7 in reply to: ↑ 6 Changed 3 years ago by
Replying to jdemeyer:
Replying to cremona:
See the attached file which crashes using 8.1's pari version. Testing suggests that this will be OK in 2.10.0.alpha, and this should be verified before this ticket is merged.
I'm not sure whether you would propose to add it as doctest, but I'd rather not since it takes quite a long time.
No, I agree. But at least we could have an assertion on this ticket that it works, so that whoever reviews the ticket (or me) can test it manually.
comment:8 Changed 3 years ago by
 Description modified (diff)
 Report Upstream changed from N/A to Reported upstream. No feedback yet.
Thanks to a Sage doctest, I found a genuine bug in the new PARI. So we'll need to wait for this to be fixed before we can proceed.
comment:9 followup: ↓ 10 Changed 3 years ago by
I could not find pari bug 2055, but 2054 is possibly similar?
comment:10 in reply to: ↑ 9 Changed 3 years ago by
Replying to cremona:
I could not find pari bug 2055
It should be there now. Their bug tracker sometimes takes a few minutes to update.
comment:11 Changed 3 years ago by
 Description modified (diff)
comment:12 Changed 3 years ago by
 Commit changed from 68662b18cf4f0e5540a0dedddfb3539cacc6ac70 to e8cd3ab7942184ad9541ac860a7a446b9407d0f0
comment:13 Changed 3 years ago by
 Description modified (diff)
comment:14 Changed 3 years ago by
 Description modified (diff)
comment:15 Changed 3 years ago by
 Commit changed from e8cd3ab7942184ad9541ac860a7a446b9407d0f0 to cceabac9faf935dd21cad0c9a55160ee90039c7b
comment:16 Changed 3 years ago by
So I ran all doctests and found 3 independent new bugs in PARI. One was already fixed in master, I reported two and one of those is already fixed. So this ticket is essentially "needs review" modulo the elleta
issue.
comment:17 Changed 3 years ago by
 Commit changed from cceabac9faf935dd21cad0c9a55160ee90039c7b to a62587a08668adf537fb3fcbb418b39dd8508b1f
comment:18 Changed 3 years ago by
 Description modified (diff)
 Report Upstream changed from Reported upstream. No feedback yet. to Fixed upstream, but not in a stable release.
 Status changed from new to needs_review
comment:19 Changed 3 years ago by
Just for information, the doctest in heegner is also touched by #25635.
comment:20 Changed 3 years ago by
 Cc ghtimokau added
comment:21 Changed 3 years ago by
 Description modified (diff)
 Status changed from needs_review to needs_work
 Summary changed from Upgrade to pari2.10.0.alpha to Upgrade to pari2.10.1.beta
comment:22 Changed 3 years ago by
 Commit changed from a62587a08668adf537fb3fcbb418b39dd8508b1f to c648214b288f031c9771bb8c021f62df814e68cd
comment:23 Changed 3 years ago by
Unfortunately, this breaks cypari2:
[cypari1.1.4] cypari2/gen.c: In function '__pyx_pf_7cypari2_3gen_3Gen_232_nf_nfzk': [cypari1.1.4] cypari2/gen.c:157941:3: error: too many arguments to function 'nf_nfzk' [cypari1.1.4] nf_nfzk(__pyx_v_self>__pyx_base.g, __pyx_v_t0>__pyx_base.g, (&__pyx_v_zknf), (&__pyx_v_czknf)); [cypari1.1.4] ^~~~~~~ [cypari1.1.4] In file included from ../../usr/local/src/sageconfig/local/include/pari/pari.h:45:0, [cypari1.1.4] from cypari2/gen.c:599: [cypari1.1.4] ../../usr/local/src/sageconfig/local/include/pari/paridecl.h:2329:5: note: declared here [cypari1.1.4] GEN nf_nfzk(GEN nf, GEN rnfeq); [cypari1.1.4] ^~~~~~~ [cypari1.1.4] cypari2/gen.c: In function '__pyx_pf_7cypari2_3gen_3Gen_234_nfeltup': [cypari1.1.4] cypari2/gen.c:158154:60: error: too many arguments to function 'nfeltup' [cypari1.1.4] __pyx_t_1 = ((PyObject *)__pyx_f_7cypari2_5stack_new_gen(nfeltup(__pyx_v_self>__pyx_base.g, __pyx_v_t0>__pyx_base.g, __pyx_v_t1>__pyx_base.g, __pyx_v_t2>__pyx_base.g))); if (unlikely(!__pyx_t_1)) __PYX_ERR(2, 4064, __pyx_L1_error) [cypari1.1.4] ^~~~~~~ [cypari1.1.4] In file included from ../../usr/local/src/sageconfig/local/include/pari/pari.h:45:0, [cypari1.1.4] from cypari2/gen.c:599: [cypari1.1.4] ../../usr/local/src/sageconfig/local/include/pari/paridecl.h:2332:5: note: declared here [cypari1.1.4] GEN nfeltup(GEN nf, GEN x, GEN zknf); [cypari1.1.4] ^~~~~~~
comment:24 Changed 3 years ago by
 Dependencies set to #25813
comment:25 Changed 3 years ago by
 Commit changed from c648214b288f031c9771bb8c021f62df814e68cd to b85a7fdad6ec8e5d23119ed310852f31bf8b770a
comment:26 Changed 3 years ago by
 Description modified (diff)
comment:27 Changed 3 years ago by
 Commit changed from b85a7fdad6ec8e5d23119ed310852f31bf8b770a to 58bde2ea1b5b031f61fbb7de771c578f4635a66b
comment:28 Changed 3 years ago by
 Dependencies changed from #25813 to #25813, #25635
comment:29 Changed 3 years ago by
 Commit changed from 58bde2ea1b5b031f61fbb7de771c578f4635a66b to 8bdbac586df58b9b55079465dba11323c6d9a7f8
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
61b0930  possibly better make_monic in heegner.py

9cbb66b  Improve make_monic

6995e7c  Merge commit '9cbb66bf5822c77fb8356af27ccc2d03401d0b25' into t/25567/upgrade_to_pari_2_10_0_alpha

adf99c0  Upgrade to pari2.10.1.beta

8bdbac5  Fix doctests for PARI/GP upgrade

comment:30 Changed 3 years ago by
 Commit changed from 8bdbac586df58b9b55079465dba11323c6d9a7f8 to 5e40504d977c0e9ecf4ab494715667d1e61a7408
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
5e40504  Fix doctests for PARI/GP upgrade

comment:31 Changed 3 years ago by
 Status changed from needs_work to needs_review
comment:32 Changed 3 years ago by
pari2.11.0 (STABLE) released !
Should we instead update to that or first update to beta and then follow up?
comment:33 Changed 3 years ago by
 Description modified (diff)
 Status changed from needs_review to needs_work
 Summary changed from Upgrade to pari2.10.1.beta to Upgrade to pari2.11
comment:34 Changed 3 years ago by
I'm experiencing a giac test failure when I update the pari nix package. I'm not sure yet if its actually caused by the pari update, the giac test suite seems somewhat nondeterministic. I'll investigate and report upstream if it is relevant.
comment:35 followup: ↓ 38 Changed 3 years ago by
Seems like I get the failure
13c13 < 1,  > matrix[[2,7,1],[3,2,1],[389,2,1],[733,2,1],[156904374622257604823879982847602392900751802349981470895277241,2,matrix> FAIL: chk_fhan11
when updating pari. The latest version of giac (1.4.969) unfortunately doesn't fix this but instead introduces one more failure:
35c35 < 2/3*sign(a)*asin(sqrt(x)*x/sqrt(a)/a),  > 2/3*asin(sqrt(x)*x/sqrt(a)/a)*sign(a), FAIL: chk_integrate
I'll have to wait until my upstream forum account is approved until I can report.
comment:36 Changed 3 years ago by
 Commit changed from 5e40504d977c0e9ecf4ab494715667d1e61a7408 to 7af4748cab37d651eaa88be501db88f4a5ffc584
comment:37 Changed 3 years ago by
 Status changed from needs_work to needs_review
comment:38 in reply to: ↑ 35 Changed 3 years ago by
Replying to ghtimokau:
Seems like I get the failure
13c13 < 1,  > matrix[[2,7,1],[3,2,1],[389,2,1],[733,2,1],[156904374622257604823879982847602392900751802349981470895277241,2,matrix> FAIL: chk_fhan11when updating pari.
Did you report that upstream?
I analyzed the problem and the problem happens because the output of isprime(p, 1)
changed from returning a primality certificate to a boolean answer. There is now a separate function primecert()
for getting a certificate.
The test directly checks the PARI interface, but otherwise these primality certificates are not used by anything in giac. So while the test fails, nothing else in giac should fail because of this.
comment:39 in reply to: ↑ 39 ; followups: ↓ 39 ↓ 40 Changed 3 years ago by
Replying to jdemeyer:
Replying to ghtimokau:
Seems like I get the failure
13c13 < 1,  > matrix[[2,7,1],[3,2,1],[389,2,1],[733,2,1],[156904374622257604823879982847602392900751802349981470895277241,2,matrix> FAIL: chk_fhan11when updating pari.
Did you report that upstream?
The only contact info I found was that forum and I'm still waiting for my account to be approved. I think I accidentally chose the wrong option at the age question (doesn't help that the forum is in french). I sent an email to the administrators, no reply yet.
If you want to try, maybe you have more luck. I wish they'd just use some issue tracker or plain old email.
I analyzed the problem and the problem happens because the output of
isprime(p, 1)
changed from returning a primality certificate to a boolean answer. There is now a separate functionprimecert()
for getting a certificate.The test directly checks the PARI interface, but otherwise these primality certificates are not used by anything in giac. So while the test fails, nothing else in giac should fail because of this.
Great, thanks for analyzing this :)
Should we then adapt / disable giac's spkgcheck
until this is fixed? Or is it okay for those spkg checks to fail?
comment:40 in reply to: ↑ 39 Changed 3 years ago by
 Cc frederichan added
Replying to ghtimokau:
I wish they'd just use some issue tracker or plain old email.
More generally, their website is a mess... Even finding the source tarballs is hard. And that page has debian
in its name even though these are just the sources: https://wwwfourier.ujfgrenoble.fr/~parisse/debian/dists/stable/main/source/
I just recall now that @frederichan is a Giac developer and usually all bug reports from Sage go through him. Frederic: if you missed the discussion, the upgrade to PARI/GP breaks one test from Giac:
13c13 < 1,  > matrix[[2,7,1],[3,2,1],[389,2,1],[733,2,1],[156904374622257604823879982847602392900751802349981470895277241,2,matrix> FAIL: chk_fhan11
See 38 for the analysis.
comment:41 followup: ↓ 43 Changed 3 years ago by
I have reported this here: https://xcas.univgrenoblealpes.fr/forum/viewtopic.php?f=4&t=2102#p10326
As this example is just calling the pari function, patching the output with the new behaviour looks natural, something like this?
 a/check/TP11sol.cas.out1 20180726 17:12:30.516949491 +0200 +++ b/check/TP11sol.cas.out1 20180726 17:13:04.397032363 +0200 @@ 10,7 +10,7 @@ 1073741824000000000000000000061203284109000000000000000000000000008409, 2^3*3*389*733*156904374622257604823879982847602392900751802349981470895277241, "Done", matrix[[2,7,1],[3,2,1],[389,2,1],[733,2,1],[156904374622257604823879982847602392900751802349981470895277241,2,matrix[[2,13,1],[3,3,1],[5,2,1],[7,2,1],[56467,2,1],[6553084925887974620811527,2,matrix[[2,5,1],[19,2,1],[71,2,1],[126823,2,1]]]]]], +1, 0, [], 1,
best Frederic
comment:42 Changed 3 years ago by
Thanks for reporting! If the test really just tests the pari interface without ever using that part of the interface, I'd just remove the test instead.
Not quite relevant to this ticket, but could you report the chk_integrate
failure too? the test failure is here. That occurs when I update giac from 1.4.959 to 1.4.969 (without changing anything else).
comment:43 in reply to: ↑ 41 Changed 3 years ago by
Replying to frederichan:
I have reported this here: https://xcas.univgrenoblealpes.fr/forum/viewtopic.php?f=4&t=2102#p10326
As this example is just calling the pari function, patching the output with the new behaviour looks natural, something like this?
Depends whether you want to want the tests to pass on older PARI versions too. Personally, I would just remove the test completely.
comment:44 followup: ↓ 45 Changed 3 years ago by
@frederichan also not really relevant for this ticket, but lacking another communication channel: Apparently the nix maintainer for giac also already requested a forum account last yer and never got it: https://github.com/NixOS/nixpkgs/pull/44129#issuecomment408203217
Regarding this ticket: I don't know how the review process works, but LGTM. I haven't run the doctests yet though.
comment:45 in reply to: ↑ 44 Changed 3 years ago by
Replying to ghtimokau:
I don't know how the review process works
Just a general reply:
 look at the diff and see whether it makes sense.
 Sage cares a lot about tests, so check whether the code is well tested.
 check the patchbot (the colored blob at the top of the page).
 maybe try a few examples, test corner cases in the code.
 if all is well: set the ticket to positive_review and add your real name as Reviewer on the Trac page. At that point, the release manager will merge the ticket in some later beta/rc release (assuming that all dependencies are merged).
In this case, this is a package upgrade, which is a bit different. The patchbot doesn't test it, so somebody should manually run the full Sage testsuite. If you want to take my word for it, I did that and tests passed.
comment:46 Changed 3 years ago by
I have also reported chk_integrate here: https://xcas.univgrenoblealpes.fr/forum/viewtopic.php?f=4&t=2104
Indeed my giac/xcas forum account is old, to obtain one I think the safest is a direct mail to Bernard Parisse: https://wwwfourier.ujfgrenoble.fr/?q=fr/content/annuaire (he may be in vacation at this time). He also have a trac account: parisse
(cf https://trac.sagemath.org/ticket/25822#comment:12)
Regarding the testsuite, although many files have my name I didn't wrote them for a testsuite so they are often too sensitive. But I think (this was often the case in the past) that bernard prefers to keep many examples and look if the changes are bugs or not. In this particular example, there are not so many giac functions that can't be run without pari (ex: ifactor still works in giac without pari), so I guess that bernard will keep this test.
For a sage package where you always have pari you may decide to suppress it.
NB: if you plan to upgrade giac package, 1.4.6.69 is not enough to fix #25822 but the next stable should be.
comment:47 followup: ↓ 48 Changed 3 years ago by
Replying to jdemeyer:
Replying to ghtimokau:
I don't know how the review process works
Just a general reply:
 look at the diff and see whether it makes sense.
Did that. While I won't pretend all the math, the changes look very reasonable to me. No obviously wrong results and I think we can trust pari with the details.
Two things that stuck out to me though:
sage: a.multiplicative_order()  4547473508864641189575195312 + 189478062869360049565633138
sage: O3.absolute_discriminant()  8643600 + 400160824478095086350656915693814563600
I would've thought that both the multiplicative order and the absolute discriminant are supposed to be unique. But again, my knowledge is limited.
 Sage cares a lot about tests, so check whether the code is well tested.
check
 check the patchbot (the colored blob at the top of the page).
Oh, I've always wondered what exactly the patchbot is everybody is talking about.
 maybe try a few examples, test corner cases in the code.
 if all is well: set the ticket to positive_review and add your real name as Reviewer on the Trac page. At that point, the release manager will merge the ticket in some later beta/rc release (assuming that all dependencies are merged).
But can anybody just do that?
In this case, this is a package upgrade, which is a bit different. The patchbot doesn't test it, so somebody should manually run the full Sage testsuite. If you want to take my word for it, I did that and tests passed.
Why doesn't the patchbot test package upgrades? I think if we can just take anybody's word for it, its probably yours.
Replying to frederichan:
I have also reported chk_integrate here: https://xcas.univgrenoblealpes.fr/forum/viewtopic.php?f=4&t=2104
Thanks :)
Regarding the testsuite, although many files have my name I didn't wrote them for a testsuite so they are often too sensitive. But I think (this was often the case in the past) that bernard prefers to keep many examples and look if the changes are bugs or not. In this particular example, there are not so many giac functions that can't be run without pari (ex: ifactor still works in giac without pari), so I guess that bernard will keep this test.
A very brittle test suite is at risk of just being ignored after a few falsepositives. I think a few highvalue tests are way more valuable than testing the literal output of every function. Sage has a bit of the same problem in my opinion.
For a sage package where you always have pari you may decide to suppress it.
For now I just did echo > check/chk_fhan11
. Its not that easy to disable an individual test.
comment:48 in reply to: ↑ 47 Changed 3 years ago by
Replying to ghtimokau:
Two things that stuck out to me though:
sage: a.multiplicative_order()  4547473508864641189575195312 + 189478062869360049565633138sage: O3.absolute_discriminant()  8643600 + 400160824478095086350656915693814563600I would've thought that both the multiplicative order and the absolute discriminant are supposed to be unique.
The multiplicative order is certainly unique, but the element a
that we're taking the order of is different.
In the second case, I changed the test input because PARI got more clever in computing orders. We need the large primes 1000003
and 1000099
to make it more difficult for PARI to accidentally find the maximal order.
 check the patchbot (the colored blob at the top of the page).
Oh, I've always wondered what exactly the patchbot is everybody is talking about.
It's what Sage uses for continuous integration. It's far from perfect and there is a proposal to replace it: #24854
But can anybody just do that?
Yes, anybody can do that. This process seems to be working fine.
Why doesn't the patchbot test package upgrades?
Good question actually, I don't know the answer.
comment:49 Changed 3 years ago by
 Status changed from needs_review to positive_review
Oh, I didn't notice that you also changed the test input.
comment:50 Changed 3 years ago by
Reviewer name.
comment:51 Changed 3 years ago by
 Reviewers set to Timo Kaufmann
comment:52 followup: ↓ 61 Changed 3 years ago by
FWIW the testsuite fails on kucalc (linux 64bit):
* Testing galpol gpsta..BUG [2116] gpdyn..BUG [2220]
comment:53 followups: ↓ 56 ↓ 62 Changed 3 years ago by
Pretty sure this is due to pari on 32bit linux:
File "src/sage/schemes/elliptic_curves/period_lattice.py", line 1463, in sage.schemes.elliptic_curves.period_lattice.PeriodLattice_ell.elliptic_logarithm Failed example: L.elliptic_exponential(_) Expected: (3.00000000000000000000000000... : 5.00000000000000000000000000... : 1.000000000000000000000000000) Got: (3.000000000000000000000000000 : 4.999999999999999999999999999 : 1.000000000000000000000000000)
I also get a lot of buildbots with giac testsuite failures, this might also be due to the pari udpate. I'll test some more... (edit: i see its already noted here)
comment:54 followup: ↓ 60 Changed 3 years ago by
PS: the patchbot doesn't test package updates since it doesn't have a programmatic way of downloading tarballs, also patchbot does incremental rebuilds which are likely to get hosed if something is wrong with the ticket.
comment:55 Changed 3 years ago by
So should this be set to needs_work then?
comment:56 in reply to: ↑ 53 Changed 3 years ago by
Replying to vbraun:
Pretty sure this is due to pari on 32bit linux:
File "src/sage/schemes/elliptic_curves/period_lattice.py", line 1463, in sage.schemes.elliptic_curves.period_lattice.PeriodLattice_ell.elliptic_logarithm Failed example: L.elliptic_exponential(_) Expected: (3.00000000000000000000000000... : 5.00000000000000000000000000... : 1.000000000000000000000000000) Got: (3.000000000000000000000000000 : 4.999999999999999999999999999 : 1.000000000000000000000000000)
That makes sense. In line 1773 the pari function ellwp() is called (in the method elliptic_exponential()) and that is what does the work for this.
I also get a lot of buildbots with giac testsuite failures, this might also be due to the pari udpate. I'll test some more... (edit: i see its already noted here)
comment:57 Changed 3 years ago by
 Status changed from positive_review to needs_work
Also I'd appreciate it if the giac testsuite could be worked around, otherwise I'll have to disabled it on the buildbot and, realistically, I'll never turn it back on.
comment:58 Changed 3 years ago by
 Commit changed from 7af4748cab37d651eaa88be501db88f4a5ffc584 to e7b4a3708094a396bd2d4924b212786365464b76
comment:59 Changed 3 years ago by
 Dependencies changed from #25813, #25635 to #26010
comment:60 in reply to: ↑ 54 Changed 3 years ago by
Replying to vbraun:
patchbot does incremental rebuilds which are likely to get hosed if something is wrong with the ticket.
That's true for any ticket. I don't believe that package upgrades are the tickets most likely to cause breakage of the patchbot.
comment:61 in reply to: ↑ 52 Changed 3 years ago by
comment:62 in reply to: ↑ 53 Changed 3 years ago by
Replying to vbraun:
Pretty sure this is due to pari on 32bit linux:
Fixed by adding some doctest tolerance.
comment:63 Changed 3 years ago by
 Commit changed from e7b4a3708094a396bd2d4924b212786365464b76 to 9e1419f8052d3e9921a178b20e2d31ff8252805e
comment:64 Changed 3 years ago by
 Commit changed from 9e1419f8052d3e9921a178b20e2d31ff8252805e to 6969b7430ab52b58f65334fa12e78433ce010421
Branch pushed to git repo; I updated commit sha1. New commits:
6969b74  Add giac patch for PARI 2.11

comment:65 Changed 3 years ago by
 Status changed from needs_work to needs_review
comment:66 Changed 3 years ago by
Ping? It would be nice to review this again. I recall that it had positive_review before. So this would need reviewing the dependency #26010 and the few added commits.
comment:67 Changed 3 years ago by
 Commit changed from 6969b7430ab52b58f65334fa12e78433ce010421 to 739f7a6acf98e7041265208836a85ab69573b36c
comment:68 Changed 3 years ago by
Rebased to latest version of #26010.
comment:69 Changed 3 years ago by
 Status changed from needs_review to positive_review
comment:70 Changed 3 years ago by
 Branch changed from u/jdemeyer/upgrade_to_pari_2_10_0_alpha to 739f7a6acf98e7041265208836a85ab69573b36c
 Resolution set to fixed
 Status changed from positive_review to closed
comment:71 followups: ↓ 72 ↓ 74 Changed 3 years ago by
 Commit 739f7a6acf98e7041265208836a85ab69573b36c deleted
Since the release of 2.11 there have been several bugfixes which are important for my current work. Some of the new mf* functions crash on 2.11.0 but run fine with the current development commit. What I am currently doing is building this development gp executable outside Sage and manually changing the link SAGE_ROOT/local/bin/gp to point to that. (My code is only using gp.eval(), not Pari library functions.
 Is there a better way?
 Is the version going to be updated regularly to the current development version of pari?
comment:72 in reply to: ↑ 71 Changed 3 years ago by
Replying to cremona:
Since the release of 2.11 there have been several bugfixes which are important for my current work. Some of the new mf* functions crash on 2.11.0 but run fine with the current development commit. What I am currently doing is building this development gp executable outside Sage and manually changing the link SAGE_ROOT/local/bin/gp to point to that. (My code is only using gp.eval(), not Pari library functions.
 Is there a better way?
As far as I can say that's quick and slightly dirty but probably not too much. I think the best way would be for your code to look for a variable, say GP_EXEC
, and use its value as the gp
executable if it exists. You can then put that in your environment and only your code is ever affected and you don't need to mess up with the link.
comment:73 Changed 3 years ago by
I thought of something like that but the Gp() constructor for a new gp interpreter does not allow the user to specify the interpreter's path explicitly. It calls Expect.__init__
with
command="gp fast emacs quiet stacksize %s"%stacksize
so that relies on picking up gp from Sage's path.
Am I missing something? I am using a personal Sage build rather than messing with the systemwide one.
comment:74 in reply to: ↑ 71 Changed 3 years ago by
Replying to cremona:
Since the release of 2.11 there have been several bugfixes which are important for my current work. Some of the new mf* functions crash on 2.11.0 but run fine with the current development commit. What I am currently doing is building this development gp executable outside Sage and manually changing the link SAGE_ROOT/local/bin/gp to point to that. (My code is only using gp.eval(), not Pari library functions.
 Is there a better way?
sage sets its PATH
in sageenv
. After setting that it sources ~/.sage/sagerc
if available. So if you create that file with the following contents:
export PATH="<insert path to local build of gp here>/bin:$PATH"
sage should pick up your gp since it is first in PATH.
 Is the version going to be updated regularly to the current development version of pari?
I don't think that is a good idea. Development versions are not for "production" use. Instead you could ask upstream for a release or suggest to them to release bugfixes in point releases.
comment:75 Changed 3 years ago by
In the long run you may also be interested in #24919.
comment:76 followup: ↓ 77 Changed 3 years ago by
Thanks for the suggestion in 1 which is certainly cleaner than whan I was doing. As for 2, it is a matter of terminology what is production and what is testing. The work I am doing is effectively a massive test of the new modular forms functionality in Pari/GP, and I am finding bugs which upstream Pari is fixing. But I am doing the testing using calls from Sage since using gp itself is much harder, especially when I get to compare the results with the output of a different package (hint: one of the 3 Ms).
Of course that is not to say that Sage should be repeatedly changing to the latest pari commit; however pari releases come around rather too infrequently.
comment:77 in reply to: ↑ 76 ; followup: ↓ 78 Changed 3 years ago by
Replying to cremona:
Thanks for the suggestion in 1 which is certainly cleaner than whan I was doing. As for 2, it is a matter of terminology what is production and what is testing. The work I am doing is effectively a massive test of the new modular forms functionality in Pari/GP, and I am finding bugs which upstream Pari is fixing. But I am doing the testing using calls from Sage since using gp itself is much harder, especially when I get to compare the results with the output of a different package (hint: one of the 3 Ms).
In that case the current solution or one through #24919 is probably best.
Of course that is not to say that Sage should be repeatedly changing to the latest pari commit; however pari releases come around rather too infrequently.
Yes that is true. But if there is something upstream we need, we should at least ask them for a release before deciding to just fetch some unstable commit.
comment:78 in reply to: ↑ 77 Changed 3 years ago by
Replying to ghtimokau:
Yes that is true. But if there is something upstream we need, we should at least ask them for a release before deciding to just fetch some unstable commit.
We can ask, but it probably won't happen just because we ask.
comment:79 Changed 3 years ago by
We should still ask. Even if it doesn't happen, they may have good reasons for that and explain them.
comment:80 Changed 3 years ago by
Bother @jdemeyer and I are in regular contact with the Pari developers anyway.
comment:81 followup: ↓ 82 Changed 3 years ago by
Having the reasons public would be better. Some explanation why the state of that particular comment is good enough for sage but not good enough for pari's upstream.
All that is hypothetical in the case that pari adds important features that we need in sage and they refuse to make a release including them in reasonable time. As far as I understand, that is not the case yet.
comment:82 in reply to: ↑ 81 Changed 3 years ago by
Replying to ghtimokau:
All that is hypothetical in the case that pari adds important features that we need in sage and they refuse to make a release including them in reasonable time. As far as I understand, that is not the case yet.
It's not the case yet, but judging from past experiences, this is likely to happen.
Sage input file which causes a pari crash with current Sage/Pari? versino