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

[Nathan Woods]

On Mon, Oct 14, 2013 at 3:22 AM, Pauli Virtanen <pav at iki.fi> wrote:

> 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
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>

Brian and I have some ideas that will make this idea work in a robust way,
at least using C++. Is there any reason to avoid dependence on C++? If so,
there may still be a way to do it in C. I actually got pretty far trying to
implement something like it in f90, but was stymied by the lack of a real
function pointer, which C has.

N
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20131018/13c3bf04/attachment.html>