Ilya Zakharevich on Sun, 30 Jun 2002 09:57:54 -0400

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: Interface definition for PARI/GP

On Sat, Jun 29, 2002 at 06:57:34PM +0200, Bill Allombert wrote:
> Currently most of the interface between the library and the language is built-in
> the file src/language/init.c as the function_basic array.
> This scheme has several short-comings:
> 1) External programs that rely on this interface need to parse this file which
> is not installed on the system (src/language/init.c, etc). This may cause
> version mismatch

What for?!  They can load PARI DLL and get this array in memory...

Or do you want to find the *name* (as opposed to the address) of the
responsible C function?

> 2) Only the information needed by GP is available.

Hmm???  The full signature is there.  What more do you want?  Help
strings?  Do not see this in your example...

> 3) To extend the interface, you need to change several files.

Again, I do not follow.  Only init.c needs to be changed.  (Supposing
that what you want is changing PARI function to reference a different
C function - with possibly different signature.)  Do you mean help
strings again?

> 5) External programs not aware of the database can still use the sources
> directly. Well it may happen that we move functions_basic to a separate file
> though.

Such moving may break the "table sanity check" features of the latest
versions of Math::Pari.  Please announce such moving...

> Function: bnfinit
> List: basic
> Section: 6
> C-Name: bnfinit0
> Prototype: GD0,L,DGp

I would prefer

  Prototype: GD0,L, DG p

> Type: gen

Is this to replace v and l tokens?

=============  Possibly of topic  ==============

Note that for transcendental functions some new fields may be needed.
Currently, one cannot take a transcendental function of a matrix, and
(this is the same issue in disguise) application of a function to a
power series often leads to problems.

To overcome this, one needs several other pieces of info.  For
simplicity, assume a function f of one argument.  The best API is:
given a polynomial P(X), emit a polynomial Q(X) such that f(X)-Q(X) is
0 mod P(X) [in the obvious sense].  E.g., for f=exp and P(X) = X^2 + pX + q

  Q(X) = 2EX + pE + cosh(sqrt(D));

here E = exp(-p/2) sinh(sqrt(D))/sqrt(D), D = p^2/4 - q.  Note that
sinh(sqrt(D))/sqrt(D) and cosh(sqrt(D)) have well-defined power series
in D.

In particular, given a 2x2 matrix A (e.g., with power series as
coefficients), one can calculate exp A using Q(X).  [I do not know
whether such an explicit representation is possible for larger deg P.]

If such a Q cannot be found by an explicit expression, one can try to
find the roots of P, and apply f to them explicitly; but to do this
for multiple roots, one needs a way to calculate the derivative of the
the given transcendental number.

So in principle, for each transcendental function one needs: 

  an algorithm to calculate Q(X) (with NULL acceptable of none);

  an algorithm to calculate all the (partial) derivatives (likewise).

Whether these should live in function_basic is debatable, of course.
Any one having some opinion pro or contra?