[SciPy-user] Automatic Differentiation with PYADOLC and Removing Boost::Python dependency
Thu Mar 26 16:00:15 CDT 2009
On Thursday 26 March 2009 13:34:16 Rob Clewley wrote:
> Ravi's points are well taken, and I do not pretend to know much about
> boost.python myself, but I am tempted to agree with David that it
> would still be more helpful to have a source-based version that does
> not depend on boost at all. Maybe Ravi could educate me as to what it
> would mean for boost.python to be more portable than python in this
On "exotic" systems (such as one with 24 bit ints and non-IEEE 754 floating
point systems), boost.python (among other well-written packages) compiles
where even python does not. Python would be a wonderful scripting language
for some embedded processor work, but I have been unable to compile python for
such platforms (perhaps because I give up if it does not compile after ~20
hours of work). Perhaps python 2.4+ may be more portable than 2.3-, but I
haven't tried compiling python on exotic systems in a while.
 Interestingly enough, python headers are much cleaner than most people
realize. Of course, when python does not compile, a boost.python static
library, when one can be created, is useless.
> As an example, I would love to use this code in PyDSTool to find
> derivatives more accurately to compute periodic orbit solutions of
> differential equations, but it does not appeal to me to require boost
> as a dependency. My impression from occasional reading of the boost
> website is that users would need to install an awful lot of additional
> things (often from source on non-windows machines) to get this
> interface to work.
Not really. In fact, no external dependencies are required other than your
reasonably standards-conformant C++ compiler. (You could optionally link
against IBM ICU for the regexp library, and optionally build an MPI interface
for some libraries if you have OpenMPI installed.) If you have a reasonably
standard python installation, boost.python will be built. The steps are:
- download boost-xxx.tar.gz
- unpack the tarfile
- cd to the bjam directory, build it
- run bjam on the boost sources
I currently use it on various linux flavors & Windows; in the past, I have
used it on Solaris and a subset on HPUX. If you have a POSIX shell, there is
even a script that does it all for you.
> Alternatively, SWIG is a lightweight additional
> dependency that easily wraps simple numpy-dependent C/C++ code, and
> this is what I use instead. I'll be delighted to learn otherwise if I
> am mistaken in my impression.
I don't consider SWIG to be a lightweight dependency, but that's merely a
matter of opinion. More importantly, SWIG does not provide easy methods to map
the C++ object model to the python object model since it uses (essentially)
opadue pointers. Overriding C++ virtual functions in python is (or at least
used to be) a pain with SWIG; SWIG also has problems with interfaces that
depend on Koenig lookup. SWIG works very well for C code, though.
More information about the SciPy-user