Package: lcalc
Version: 1.23+dfsg-3
the current debian package doesn't work as well as sagemath hopes it to:
jpuydt@cauchy:~$ lcalc -z 3 -e --a1 0 --a2 0 --a3 1 --a4 -1 --a6 0
*** Warning: new stack size = 1028928 (0.981 Mbytes).
*** Error in the PARI system. End of program.
whereas using sagemath's version (on another box) :
(sage-sh) jpuydt@localhost:sage-6.4.1$ lcalc -z 3 -e --a1 0 --a2 0 --a3
1 --a4 -1 --a6 0
0
5.00317001401
6.87039121695
indeed, one of sagemath's patches against lcalc is to use a larger pari
stack -- it is named init_stack.patch and contains :
diff -ru src/include/Lcommandline.h b/include/Lcommandline.h
--- src/include/Lcommandline.h 2012-08-08 23:21:55.000000000 +0200
+++ b/include/Lcommandline.h 2014-01-06 14:04:55.981027532 +0100
@@ -40,12 +40,7 @@
#include "Lcommandline_globals.h" //command line global variables
#ifdef INCLUDE_PARI
#include "pari.h" //for pari's elliptic curve functions
-#undef init //pari has a '#define init pari_init' which
- //causes trouble with the stream.h init.
- //pari also causes trouble with things like abs.
- //we place the pari include first since
otherwise it
- //messes up.
-
+#include "paripriv.h" //for pari_init_stack()
#endif //ifdef INCLUDE_PARI
diff -ru src/src/Lcommandline.cc b/src/Lcommandline.cc
--- src/src/Lcommandline.cc 2012-08-08 23:21:56.000000000 +0200
+++ b/src/Lcommandline.cc 2014-01-06 14:02:19.463388366 +0100
@@ -473,7 +473,9 @@
#ifdef INCLUDE_PARI
if(do_elliptic_curve){
- allocatemoremem((int) N_terms*16+1000000); //XXXXXXXXX
this should depend on whether we're double or long double or mpfr double
+ // Reallocate PARI stack
+ pari_init_stack((size_t)N_terms*16 + 1000000, top-bot);
//XXXXXXXXX this should depend on whether we're double or long double or
mpfr double
+
if (my_verbose>0) cout << "Will precompute " << N_terms
<< " elliptic L-function dirichlet coefficients..." << endl;
initialize_new_L(a1,a2,a3,a4,a6,N_terms);
}
This patch doesn't seem to apply cleanly, and even so the include needs
a "pari/paripriv.h", but it looks like something like this would help us.
I will work on this problem in debian-science's git, but I still wanted
it clearly reported.
Snark on #debian-science
--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
