On 03/08/2010 02:11 PM, Jim Bosch wrote:
I think it would be useful to integrate the PyArray wrapper right into
boost.python.
I generally agree, but I dislike the idea of including the numpy C-API
header file in all its preprocessor-macro glory in a file which will be
included by users, and I've found it hard to avoid that in a header-only
library. What was your solution?
In my setup I check for the python-numpy package (on Fedora), which
provides the numpy/arrayobject.h header (assuming this is the one you mean).
However, I'm not sure I understand your concern. Boost.python isn't a
header-only library, so it may well hide the above header by compiling
it into its own object file.
To me, the most important feature in adding proper PyArray support to
boost.python is the ability to access the much richer API, such as
direct-data access via PyArr_DATA, PyArr_GETPTRX, etc., which allow me
to build my own adapter, so different parts of a hybrid application can
pass arrays around without the need to copy.
Other libraries which provide more functionality (such as pyublas, or
the one Jim is talking about) can then use that wrapper, instead of
having to provide it themselves. This should notably also improve
interoperability, since the boost.python type registry doesn't (yet)
allow multiple wrappers for the same types.
This does seem like the best way to go, if we can find a solution to the
numpy header problem that doesn't require building the boost.python
library itself against numpy.
Hmm, this is a good point: By compiling the numpy wrapper as part of
boost.python, we would make numpy a prerequisite for boost.python, which
isn't a good idea. So keeping it header-only may be better.
I'm still not sure what your concern is with the numpy header. Why can't
it be exposed to user code ?
May be you can indeed make a case for a compiled boost.numpy library...
By the way, here's what I've got - it seems to complement pyublas pretty
well:
- A few "object manager" types for numpy.ndarray, numpy.dtype,
numpy.matrix, and numpy.void scalars, and a pretty easy system for
adding more. These present a boost.python interface to the parts of the
Numpy C-API, and it sounds like they're pretty similar in spirit to your
PyArray. I'll look into putting them into the sandbox.
That looks good. Thanks !
- A tool for creating broadcasting python callables from arbitrary C++
objects that overload operator().
Would this be a generator for ufuncs ?
- A multidimensional array template library patterned after numpy; this
is definitely not something that belongs in boost.python, but I find
that they work very well together:
http://code.google.com/p/ndarray/
Ah. That sounds useful, but I agree, not like something that belongs
into a generic numpy wrapper library.
It would really great if boost.multiarray could fill such a role, but I
found it doesn't do everything needed in talking to numpy - particularly
the ability to handle shared data.
Thanks. I'd very much like to see a discussion of how to move the above
numpy wrapper into boost.python (possibly as a new compiled boost.numpy
library).
Thanks,
Stefan
--
...ich hab' noch einen Koffer in Berlin...
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
