[SciPy-user] Automatic Differentiation with PYADOLC and Removing Boost::Python dependency

[Sebastian Walter]

On Thu, Mar 26, 2009 at 4:41 PM, Ravi <lists_ravi at lavabit.com> wrote:
> Hi Sebastian,
>  Thank you for writing a wrapper for ADOL-C.
>
> On Thursday 26 March 2009 05:50:24 Sebastian Walter wrote:
>> I have implemented a wrapper for  the C++ Automatic Differentiation
>> (AD) tool ADOL-C.
>> You can use it to differentiate complex algorithms to arbitrary order.
>> It works quite well with numpy.
>>
>> You can have a look at it at http://github.com/b45ch1/pyadolc .
>
> >From a quick look at your code, the C++ wrapper seems really nice. The python
> wrapper, though, has some cosmetic problems:
>
> 1. The entry point function BOOST_PYTHON_MODULE( _adolc ) should be part of
> the cpp file, not the hpp file.
ok, I could change that. It works though.

>
> 2. In my experience, it is difficult to maintain docstrings in the C/C++
> portion of the code. It would be a lot easier to add the docstrings to the
> python part of the python wrapper; see the boost.python documentation for
> examples. With this method, if the docstrings need to change, you will not
> need to recompile the C/C++ files.
I thought about that too. If I did the project again, I would do it that way.
 It's the question what costs more time: changing the code or keeping the code.
Up to now changes to the docstrings were very rare, so I'll keep it
that way for now.

>
> 3. I don't understand why the addition of unary operators for badouble messes
> up any remaining computations. Could you please post a reduced example on
> cplusplus-sig exhibiting the problem?

Ermm, well, to be honest, that's something I do not fully understand myself!
The problem is that ADOL-C is internally quite a hack and I have only
limited understanding how boost::python works internally.
 When the constructor of a badouble is called, the badouble object is
given a unique id.
Somehow, pyadolc used the same ID twice, if i remember correctly. It's
quite a while when I had that problem.

>
> [snip example usage]
>
>> Removing Boost::Python dependency ?
>> ===============================
>>
>> I have used Boost::Python to wrap it, but I am not happy with that
>> additional dependency!
>> So I wondered if someone could give me advice how to avoid users
>> having to download and install boost::python to use pyadolc.
>> (include boost::python sources ? port to C API?)
>
> Predictably, I would recommend against removing the boost.python dependency.
> While there are parts of boost where development speed outstrips the ability
> of the authors of dependent packages to keep up, boost.python is not one such
> part. Second, the transparent usage of boost.python in your code is pretty
> much immune to changes even in boost.python since you do not use "complex"
> features like custom converters. What you have is very easily maintainable,
> and requires no tools other than your C++ compiler, which is a big selling
> point for some applications of your code. Finally, boost.python is more
> portable in some cases than even python; I disagree with David C here, but my
> experience is the only sample point I have from which to compute statistics.
>
> Given the straightforward nature of your boost.python usage, it will compile
> with boost versions from 1.34.1 (perhaps even older versions) to the
> forthcoming 1.39. Most (if not all) linux distributions supply one of those
> versions of boost. For linux users, your code is straightforward to compile
> and use (though I'd have preferred a CMake-based system). For Windows users,
> you can provide binaries built against the Boost Consulting boost-1.37
> binaries and supply the 3 relevant boost DLLs as part of your download. FWIW,
> at my workplace, we have some python bindings which are about the same level
> as yours which we encourage our customers to build against the Boost Computing
> binaries.

That sounds reasonable. I havent used Windows in a while and I thought
that it might be hard to distribute it
with the boost dependency.

>
> Hope this helps.
>
> Regards,
> Ravi
>
>
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-user
>