[C++-sig] Status of Numpy support in boost python
Hello Everyone, we are working on a project for which it would be extremely useful if numpy arrays could be passed as arguments to wrapped C++ methods. On the website I cannot find any evidence that this is currently supported by Boost Python. Is this (or will this be) implemented? Kind regards, Pim Schellart ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Status of Numpy support in boost python
On 03/08/2010 07:32 AM, Pim Schellart wrote: Hello Everyone, we are working on a project for which it would be extremely useful if numpy arrays could be passed as arguments to wrapped C++ methods. On the website I cannot find any evidence that this is currently supported by Boost Python. Is this (or will this be) implemented? At present, boost.python provides an 'array' type that corresponds to Python's numpy.ndarray. However, the wrapper isn't rich enough for example to pass raw data pointers, making it not suitable for some applications. Docs for the existing facilities can be found at http://www.boost.org/doc/libs/1_41_0/libs/python/doc/v2/numeric.html. We have had a couple of discussions about improving boost.python's support for numpy, but nothing materialized yet. May be we should rally up enough momentum to get this done. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin... ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Status of Numpy support in boost python
On Mon, 2010-03-08 at 08:08 -0500, Stefan Seefeld wrote: > On 03/08/2010 07:32 AM, Pim Schellart wrote: > > Hello Everyone, > > > > we are working on a project for which it would be extremely useful if > > numpy arrays could be passed as arguments to wrapped C++ methods. > > On the website I cannot find any evidence that this is currently > > supported by Boost Python. > > Is this (or will this be) implemented? > > > > At present, boost.python provides an 'array' type that corresponds to > Python's numpy.ndarray. > However, the wrapper isn't rich enough for example to pass raw data > pointers, making it not suitable for some applications. > > Docs for the existing facilities can be found at > http://www.boost.org/doc/libs/1_41_0/libs/python/doc/v2/numeric.html. > > We have had a couple of discussions about improving boost.python's > support for numpy, but nothing materialized yet. May be we should rally > up enough momentum to get this done. > > I have fairly complete library along these lines that I have been slowly cleaning up for public release, and I could probably submit a fairly complete proposal over the next few weeks if there is interest. It's met my needs quite well over the past few years, but I think it would benefit from input from the community. Is there someplace standard for hosting/publishing extensions to boost.python that I should be aware of? What I would consider a compute Numpy interface is probably not something that should be added into the main boost.python library itself (and I think it would need it's own shared library if done properly). Jim Bosch ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Status of Numpy support in boost python
On 03/08/2010 01:20 PM, Jim Bosch wrote: I have fairly complete library along these lines that I have been slowly cleaning up for public release, and I could probably submit a fairly complete proposal over the next few weeks if there is interest. It's met my needs quite well over the past few years, but I think it would benefit from input from the community. Is there someplace standard for hosting/publishing extensions to boost.python that I should be aware of? What I would consider a compute Numpy interface is probably not something that should be added into the main boost.python library itself (and I think it would need it's own shared library if done properly). Oh, interesting. I have written a PyArray wrapper myself, and it is only a single header right now. For a full library I would certainly suggest the sandbox. There we may discuss, and then merge into trunk as we see fits. (I'd suggest boost/sandbox/numpy for this.) Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin... ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Status of Numpy support in boost python
>Jim Bosch wrote: > On Mon, 2010-03-08 at 08:08 -0500, Stefan Seefeld wrote: >> On 03/08/2010 07:32 AM, Pim Schellart wrote: >> > Hello Everyone, >> > >> > we are working on a project for which it would be extremely useful if >> > numpy arrays could be passed as arguments to wrapped C++ methods. >> > On the website I cannot find any evidence that this is currently >> > supported by Boost Python. >> > Is this (or will this be) implemented? >> > >> >> At present, boost.python provides an 'array' type that corresponds to >> Python's numpy.ndarray. >> However, the wrapper isn't rich enough for example to pass raw data >> pointers, making it not suitable for some applications. >> >> Docs for the existing facilities can be found at >> http://www.boost.org/doc/libs/1_41_0/libs/python/doc/v2/numeric.html. >> >> We have had a couple of discussions about improving boost.python's >> support for numpy, but nothing materialized yet. May be we should rally >> up enough momentum to get this done. >> >> > > I have fairly complete library along these lines that I have been slowly > cleaning up for public release, and I could probably submit a fairly > complete proposal over the next few weeks if there is interest. It's > met my needs quite well over the past few years, but I think it would > benefit from input from the community. > > Is there someplace standard for hosting/publishing extensions to > boost.python that I should be aware of? What I would consider a compute > Numpy interface is probably not something that should be added into the > main boost.python library itself (and I think it would need it's own > shared library if done properly). > > Jim Bosch Check out pyublas ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Status of Numpy support in boost python
On 03/08/2010 01:30 PM, Neal Becker wrote: Check out pyublas Thanks for mentioning that. Yes, this looks very useful. In fact, my PyArray wrapper was inspired by pyublas. I think it would be useful to integrate the PyArray wrapper right into boost.python. 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. Stefan -- ...ich hab' noch einen Koffer in Berlin... ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Status of Numpy support in boost python
On Mon, 2010-03-08 at 13:40 -0500, Stefan Seefeld wrote: > On 03/08/2010 01:30 PM, Neal Becker wrote: > > > > Check out pyublas > > > > Thanks for mentioning that. > > Yes, this looks very useful. In fact, my PyArray wrapper was inspired by > pyublas. Definitely useful, and from what I've seen from a quick glance, a very nice API. I'm personally using Eigen2 rather than boost.ublas - do you have any comment on whether this could be made more generic so as to support other C++ matrix libraries? Of course, ublas is in boost, so it's clearly the most important target. > 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? > 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. 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. - A tool for creating broadcasting python callables from arbitrary C++ objects that overload operator(). - 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/ 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. Jim ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Status of Numpy support in boost python
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 [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Status of Numpy support in boost python
On Mon, 2010-03-08 at 14:38 -0500, Stefan Seefeld wrote: > 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. > I agree. The whole point of using numpy with C++ is to be able to go from raw pointers to numpy arrays and back, and that doesn't seem to be possible with an interface that just calls the Python API (as the numeric interface does at present). > > 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 ? > I just don't like that you have to #define something before including the header, and that it's different in the source file that calls "import_array()" than in all the others. In fact, I find it unfortunate that "import_array()" needs to be called at all, but I haven't found a way around that. I'm also mildly annoyed that it doesn't #include even though it requires it. This is all just a really ugly replacement for namespaces, and it may be necessary in C extensions, but shouldn't be necessary in a C++ extension. You should be able to just do "#include > > - A tool for creating broadcasting python callables from arbitrary C++ > > objects that overload operator(). > > > > Would this be a generator for ufuncs ? > Not in any technical sense of the word "generator", I think, and it doesn't actually use the numpy.ufunc type (because that requires a true function pointer), but that's essentially the idea. Finally, I've checked in what I have so far in the sandbox: http://svn.boost.org/svn/boost/sandbox/numpy/ There's still a lot to do before I'd call it complete, but it has (IMO) the most important low-level functionality. If anyone wants to toss in a bjam-based build system, I'd much appreciate it - I don't know jam at all. Jim ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Status of Numpy support in boost python
On 03/08/2010 04:57 PM, Jim Bosch wrote: 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 ? I just don't like that you have to #define something before including the header, and that it's different in the source file that calls "import_array()" than in all the others. In fact, I find it unfortunate that "import_array()" needs to be called at all, but I haven't found a way around that. I'm also mildly annoyed that it doesn't #include even though it requires it. This is all just a really ugly replacement for namespaces, and it may be necessary in C extensions, but shouldn't be necessary in a C++ extension. You should be able to just do "#include Right. And that's all the users of my wrapper do. Everything else happens within my wrapper code. Finally, I've checked in what I have so far in the sandbox: http://svn.boost.org/svn/boost/sandbox/numpy/ Thanks, I'll have a look. There's still a lot to do before I'd call it complete, but it has (IMO) the most important low-level functionality. If anyone wants to toss in a bjam-based build system, I'd much appreciate it - I don't know jam at all. I'm little better, but will try to clone something I know works. Ping me in a couple of days, if you haven't heard back from me. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin... ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
[C++-sig] The C language for Python programmers --- PythoidC
Hi,
if you want to write and run C code in Python IDE with auto-completion
if you want to introspect into C functions and data structs
if you hate the {} and ; and the DOS window (console)
Please take a look at:
http://pythoidc.googlecode.com
PythoidC is the C language like the Python, by the Python and for the Python
import c
c.include(c.h.stdio)
c.include(c.h.stdlib)
'''Annotation is free!'''
int fib(int n):
if(n<=2):
return1
else:
return fib(n-1)+ fib(n-2)
int main(int argc,char**argv):
int n //C style annotation
n=c.stdlib.atoi(argv[1])
c.stdio.printf('fibonacci(%d)=%d\n', n, fib(n))
___
Cplusplus-sig mailing list
[email protected]
http://mail.python.org/mailman/listinfo/cplusplus-sig
