Bill Allombert on Tue, 19 Nov 2002 16:30:34 +0100 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
Re: GP as a programming language |
On Fri, Nov 15, 2002 at 01:40:44PM -0800, Ilya Zakharevich wrote: > [Subject changed; in the middle of composing the previous message I > changed my mind what should the focus of the message, but forgot to > change the subject.] > > On Fri, Nov 15, 2002 at 01:21:31PM +0100, Bill Allombert wrote: > > On Thu, Nov 14, 2002 at 06:28:31PM -0800, Ilya Zakharevich wrote: > > > I think that the principal reason for slow uptake of GP/PARI is how > > > painful it is to extend it. When one extends in C, one needs to fight > > > with PARI being so C-hostile [one essentially program in assembler, > > > using (GEN)z[n] instead of z->array[n] - or at least VEC_elt(z,n) as > > > in my recent patch; likewise for access to components of other types] > > > and the API is so un-mneumonic. It is very hard to read existing code > > > (to improve, or to model one's own code on an existing one). > > > > That is what of the point of writing GP2C. > > See the end of my previous message. gp2c is in the same ballpark as > Math::Pari. Math::Pari did not help GP/PARI. I see no reason why > gp2c would. gp2c allow to produce C code from GP code more easily. You do not need to care about the PARI syntax since gp2c handle this for you. If you have a working GP script you can use gp2c to translate it to C code and then add it to PARI. The file src/basemath/perm.c was done this way. So I believe it make extending PARI/GP easier. Cheers, Bill