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

[Pauli Virtanen]

Nathan Woods <charlesnwoods <at> gmail.com> writes:
[clip]
> In my opinion, the best way to solve the first problem is
> to take advantage of the OOP programming style. Functional
> programming, as used in SLATEC and much of SciPy, is expressly
> designed to prevent the passing of information around the
> program through anything other than the functional interface.
> In FP, f(x) cannot depend on anything other than x, and if it
> depends on x and y, then it absolutely must be written f(x,y).
> The current implementation uses global variables to cheat around
> this restriction, and pass y in through the back door, as it were.
> A perhaps safer alternative is to define f as a bound method to
> an object, and use object variables instead of global variables
> to pass the y,z,... to the function, leaving the interface as
> f(x), just as Quadpack wants it. There's an example of this in
> scipy.integrate.nquad, if anyone is interested. This could be
> fairly easily and safely implemented in Fortran 2003, but that
> is not as widely supported as I think scipy needs. That leaves
> either C, or C++.
[clip]
> Comments welcome.

What you write above is problematic --- you assume that
C and Fortran have similar metaprogramming capabilities as Python.
This is not the case, which makes what you propose above
impossible.

Bound methods do not exist in C or Fortran, even if allowing for 
OO programming that C++ and Fortran 2000+ bring. Moreover,
signatures of all functions to be called must be known at compile
time.

Metaprogramming can be done in principle, but this requires
on-the-fly code generation, which I believe is not a feasible
solution here. The solution to the problem at hand must necessarily
be more restricted.

-- 
Pauli Virtanen