On Nov 20, 2007 12:44 PM, Anton Mellit <[EMAIL PROTECTED]> wrote: > Sorry, I overlooked the question and only saw it now. > > > > What are you using to link Python and Pari's C? > > > In pari there is a special database (in the 'desc' directory of the > source distribution) of all functions that are exposed to the > interpreter. So I use a perl script that for each function in the list > generates a python function using certain conventions for transforming > parameters. In pari there are several types of parameters and you need > to handle them appropriately. The easiest cases are when parameter is > a GEN or a long, so you don't need any special handling. > > I explain on the example of intnum. Pari's intnum is called as > follows: > intnum(t=0,1, t^2). > So the actual C function takes 4 parameters. The first one is a > 'variable', which has the type "entree". Then come two limits of > integration, and finally a string which will be parsed later. So the > function intnum sets the value of this entree and evaluates the string > to get the value of the integrand at a certain point. > In python the function is called like this: > intnum(0,1,lambda t: t^2) > My realization of intnum creates an empty entree, and as the string to > evaluate it sends special string that contains a reference to this > entree and a reference to the python function (which was given by > lambda t: t^2). Also there is a way in PARI to override the parser > which will parse a string. If you send a sequence of strings which > starts with a certain character then my parser is called. So my parser > simply extracts the references to the entree and to the function, > reads the value from the entree and calls the functions with this > value as the argument.
Does this actually work, i.e., numerical integration from the python interpreter via PARI? And is it just as fast as doing it from gp? I remember quite awhile ago that I could never get intnum to work reliably in C library mode, though it worked from via the gp command line. > So as soon you know what to do with each parameter type you simply > 'import' all pari's function using a script. > Thanks for the explanation. Definitely your wrapping of PARI is much much much different than what we do in Sage. Ours is not automated, and indeed we change some of the semantics (e.g., indexing is 0-based instead of 1-based) and some function even behave differently, e.g., our factor routine always gives answers provably correctly unlike PARI's. Another interesting aspect of our approach is that if you do, e.g., >>> pari(2**997 - 1).factor() you can hit control-c to escape out of it at any point. Also, with our wrapper if pari runs out of memory doing a step of a calculation it will automatically double the stack and redo the calculation. It also copies all results of calculations out of the pari stack into the Python heap, so that Python's memory management is used to deal with (reference counted) garbage collection. Currently when an error occurs in PARI the PARI C library calls sigint and Sage catches it then recovers gracefully. As Bill Allombert explained at Sage days 6, this is completely wrong, and instead Sage should be installing its own error handler. This is now on the todo list. -- William --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-forum URLs: http://sage.math.washington.edu/sage/ and http://sage.scipy.org/sage/ -~----------~----~----~----~------~----~------~--~---
