Re: gp_read_str

[Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>]

On Wed, Jun 20, 2012 at 06:27:24AM +0200, Dirk Laurie wrote:
> 2012/6/15 Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>:
> 
> > Mayeb there are nicer ways to do that with PARI 2.5.
> > For example you do
> > GEN code = gp_read_str("(a,b,c)->a*(b-c)");
> > and then
> > GEN res = closure_callgenvec(code, mkvec3(a,b,c))
> >
> 
> Thanks, that solves my problem completely.  Two more questions, though.
> 
> 1. Maybe in view of the usefulness of the above suggestion the statement
>    below is a little too discouraging, especially since §11.1 documents
>    closure_callgenvec and some other functions too.
> 
>   4.5.19 Type t_CLOSURE (closure).: This type hold GP functions and closures,
>   in compiled form.  It is useless in library mode and subject to change
>   each time the GP language evolves. Hence we do not describe it here and
>   refer to the Developer's Guide.

I agree. There are valid use of t_CLOSURE now (we even provide a way to convert C
functions to t_CLOSURE). The documentation is right that the internal of the t_CLOSURE
type belong to the Developer's Guide, but not the high-level functions which indeed 
are described in the section 'Handling closures' of the libpari manual

> 2. Is there a way to find out the arity of the closure before calling
>    it?  

You can use the following function

long closure_arity(GEN C)    { return C[1]; }

which was unfortunately omited in 2.5

> Even better, to have access to the entree of the closure?

t_CLOSURE do not have entree associated to them.  (Installed functions do, but
they are not t_CLOSURE).

Cheers,
Bill.