Re: New experimental GP parser release 2.4.1.bill-1

[Walter Neumann <neumann@math.columbia.edu>]

make bench fails from me on "Testing elliptic" using the gmp kernel (it is 
fine with the default kernel).  Here is elliptic-dyn.dif:

*** ../src/test/32/elliptic	2006-10-09 15:15:44.000000000 -0400
--- gp.out	2006-10-10 20:00:21.000000000 -0400
***************
*** 158,164 ****
  ? precision(cmcurve)
  38
  ? getheap
! [139, 5245]
  ? print("Total time spent: ",gettime);
! Total time spent: 336
  ? \q
--- 158,164 ----
  ? precision(cmcurve)
  38
  ? getheap
! [141, 5259]
  ? print("Total time spent: ",gettime);
! Total time spent: 32
  ? \q


GP/PARI CALCULATOR Version 2.4.1 (bill)
i686 running linux (ix86/GMP-4.1.4 kernel) 32-bit version
compiled: Oct 10 2006, gcc-4.1.1 20060525 (Red Hat 4.1.1-1)
(readline v5.0 enabled, extended help enabled)

--walter

On Tue, 10 Oct 2006, Bill Allombert wrote:

> Hello PARI-dev,
>
> I have made available a new version of my experimental GP parser:
> <http://pari.math.u-bordeaux.fr/~bill/pari-2.4.1.bill-1.tar.gz>
>
> The experimental way to handle local variables has been removed. Instead
> this version implement local variables and recursives functions the same
> way as GP. This was the main incompatibility with regular GP.
>
> It also fixes a lot of bugs that were in the previous version.
> In particular, this passes the GP2C test-suite.
> ( Run make gp;./dotest to try the test-suite.)
>
> GP lists are not supported (because I don't know how they are
> supposed to be managed).
>
> On some examples, it is four time faster than standard GP.
>
> An experimental feature I plan to add is allowing to use local()
> (almost) anywhere.
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> This new parser is nearly a five-year old project now so it might be
> time to complete it. But we need your help:
>
> If we are going to switch to this parser, we need to build a
> comprehensive test-suite of GP behaviour. To that end, if you have
> scripts (or could write some!) that rely more on the language features
> than on number crushing or on library functions please send them to me
> together with an example of usage so I can use it as part of a
> test-suite.
>
> Cheers,
> Bill.