[SciPy-Dev] Beginning work on robustly allowing function pointers in integrate - quad

[Pauli Virtanen]

Nathan Woods <charlesnwoods <at> gmail.com> writes:
> On Thu, Oct 10, 2013 at 3:16 PM, Pauli Virtanen <pav <at> iki.fi> wrote:
[clip]
> > What sort of C/Fortran signatures should be accepted? The simplest
> > option is probably to just support user functions of the form
> >         return_t func(..., void *params)
> > where `...` are the arguments as they are passed in by the Fortran/C
> > algorithm code, and `*params` is then tacked on by indirection. This
> > removes the need for multiple trampoline routines.
> 
> I'm not sure I follow you here. I think you're referring to only
> accepting user functions that return a single argument, with a pointer
> to some additional parameters? Can you give an example of such a parameter
> as it would be used in, say, integrate?

The quad callback would be `double f(double *a, void *params)`.
The call signatures of course depends on the routine. Perhaps it should
also be standardized.

What I mean here is that while in Python, you can do `f(arg1, arg2, *a, **kw)`
there's no way in C to make calls with `*a` and `**kw` without on-the-fly
code generation. Which we don't want to do --- too complicated.
The best option is to keep it simple.

[clip]
> I guess I thought that we were talking about replacing most of the
> code in quad(). As far as I can tell, the integrate library uses the
> C/Python API to communicate with the underlying Quadpack code. One of
> the main difficulties I see is that the C/Python API is fairly complex,
> and therefore the wrapper code is difficult to modify. I'd be a lot
> happier if this could be done with one of the simpler tools
> (probably Cython, since that seems to be the way the community is
> leaning), so that the interface doesn't become a magic black box.

The quadpack wrappers could probably be done with f2py without too
many problems.

-- 
Pauli Virtanen