[SciPy-Dev] First Steps in function pointer integration into quadpack

Brian Lee Newsom Brian.Newsom at Colorado.EDU
Tue Nov 5 12:45:26 EST 2013


Hello all,

So Nate and I have been working further towards how to speed up quadpack
and our solution comes down to using c function pointers that will allow
skipping the recursion that requires using python at every step.

As a first step, we have prototyped what it would look like, in plain c, to
interface with the quadpack fortran library.  Ideally once this c is fully
written, we will just have to figure out how to get function pointers from
cython/ctypes/etc. into plain c from python.

  Unfortunately, as far as I can tell, we must cast the function passed in,
in order to evaluate it, and this has lead to an ugly solution (actually
two):
1. Use a switch statement based on the number of args (t1,t2..,tn) - really
ugly, but works.  Also provides a limit on the number of arguments a
function may contain.
OR
2. Make the user have a function of the form function(args[]) instead of
function(x1,x2,x3) so that regardless of number of parameters the function
signature will look the same.  Keep in mind the user will already have to
use ctypes or cython so they will already be going out of their way to
declare this function differently so it can be integrated faster.

Is either of these an acceptable solution? Or is there a better way that I
am missing from my limited knowledge of c?

Secondly,
In basing this code generally off of quadpack.py, quadpack.h and
__quadpack.h there seems to be a lot I ommitted and still gained the
functionality I currently have.  Is there anything important I ommitted
that will make this not robust or open up problems that I don't expect?
 Any C advice would be helpful.

So currently this code solves the issue of evaluating a multidimension
function as a function of just one double *x so that it can interface the
fortran.  It does this by initializing the function and saving it to a
global void pointer along with a global argument array of doubles for
integration over higher dimensions.  This should allow for an analogue to
nquad for multidimension integration that does not need to callback to
python constantly.

C file included in gist:
https://gist.github.com/BrianNewsom/7322797
To compile, I used:
     gcc globalmethod.c -L. -lslatec -lgfortran
where libslatec.a is a compiled library containing at least dqag and it's
dependencies.

Thank you for any advice or criticism,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20131105/7e7e1897/attachment.html>


More information about the SciPy-Dev mailing list