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

[Nathan Woods]

On Fri, Oct 18, 2013 at 10:42 AM, Pauli Virtanen <pav at iki.fi> wrote:

> Hi,
>
> 18.10.2013 19:07, Nathan Woods kirjoitti:
> [clip]
> > 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.
>
> I'm assuming you are speaking here about passing in function pointers
> carrying extra arguments, without using global variables or modifying
> QUADPACK code.
>
> Please line out how you would do it in C++. Note that things such as
> std::bind and taking addresses of member functions will not help here,
> because they require passing in not only a function pointers but also
> the binding object separately. This issue is outlined in the C++ FAQ ---
> the situation with QUADPACK is analogous to event callbacks:
>
> http://www.parashift.com/c++-faq/memfnptr-vs-fnptr.html
>
> --
> Pauli Virtanen
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>

Your note at the end was helpful, as that is exactly what we were planning.
It would seem, however, that std::bind may still work, provided that the
function being bound is not an object method. So, given a normal function
f(obj,x,y,z,t) that wraps an object and its method, perhaps bind would be
fine. That does leave some questions about how to eventually implement
recursion, though.

To be honest, I'm starting to wonder if the whole thing would just be
easier to handle with COMMON blocks in F77, which at least aren't quite
global. I don't know what that might do to future parallelization efforts,
but it would work for this. At what point do global variables become the
least-painful answer to this problem?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20131018/bc420c0f/attachment.html>