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

[Nathan Woods]

Strike that last. COMMON blocks are pretty much the same thing as global
variable.


On Fri, Oct 18, 2013 at 11:07 AM, Nathan Woods <charlesnwoods at gmail.com>wrote:

>
>
>
> 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/f2d52d1c/attachment.html>