[Numpy-discussion] numpy.ndarrays as C++ arrays (wrapped with boost)

Alexander Schmolck a.schmolck@gmx....
Tue Sep 11 17:25:45 CDT 2007

Philip Austin <paustin@eos.ubc.ca> writes:

> Alexander Schmolck writes:
>  > So my question is: might it make sense to use (a slightly wrapped)
>  > numpy.ndarray, and if so is some code already floating around for that (on
>  > first glance it seems like there's a bit of support for the obsolete Numeric
>  > package in boost, but none for the newer numpy that supercedes it); if not is
>  > my impression correct that making the existing code numpy compatible shouldn't
>  > be too much work.
> Right, it should work more or less as is if you just do:
> set_module_and_type("numpy", "ArrayType");

Ah, I guess that's the advantage of going via python, rather than calling the
C-api directly (although I assume it must be rather costly).

> in the examples.  Some tests will fail because of numpy changes to
> function signatures, etc.
> The current library doesn't wrap numpy.zeros, numpy.ones or
> numpy.empty constructors, so the only way to construct an empty
> is to pass the constructor a tuple and then resize.  Because
> it (by design) doesn't include arrayobject.h, there's also no clean
> way to get at the underlying data pointer to share the memory.

Not being able to get at the data-pointer sounds like a show-stopper for this
purpose -- I will almost certainly need to interface to exisitng C and C++
code, and I do not intend to copy hundres of MB around unnecessarily.

I think it is a real shame that boost currently doesn't properly support numpy
out of the box, although numpy has long obsoleted both numarray and Numeric
(which is both buggy and completely unsupported). All the more so since
writing multimedial or scientific extensions (in which numpy's array interface
is very natural to figure prominently) would seem such an ideal use for
boost.python, as soon as complex classes or compound structures that need to
efficiently support several (primitive) datatypes are involved, boost.python
could really play its strenghts compared to Fortran/C based extensions.

I've since stumbled (in the numpy-list) upon


which seems like it could offer a great fit for my needs, but unfortunately
it's not really documented and there's also no indication how ready for use it
is -- I'd be interested to hear if anyone has an experience-report to offer;
if not I guess I might just end up settling for std::vector for the time
being, I need something workable soon, and it doesn't look like it'd be able
to figure it out and verify that it works for me without a substantial time

> You can use helper functions like this, though:
> //Create a one-dimensional numpy array of length n and type t
> boost::python::numeric::array makeNum(intp n, PyArray_TYPES t=PyArray_DOUBLE){
>   object obj(handle<>(PyArray_FromDims(1, &n, t)));
>   return extract<boost::python::numeric::array>(obj);
> }
> http://www.eos.ubc.ca/research/clouds/software/pythonlibs/num_util/num_util_release2/Readme.html

Thanks! This looks rather useful, I will try it on some data I need to convert
to pass to python tomorrow.


More information about the Numpy-discussion mailing list