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? Ilya