On 03/24/2011 06:31 AM, Neal Becker wrote:
Jim Bosch wrote:
On 03/23/2011 07:49 AM, Stefan Seefeld wrote:
Hello,
As you may have heard, Boost has once again been accepted as a mentoring
organization in this year's Google Summer of Code program. One of the
potential projects that we have been talking about in the past is about
improving the NumPy wrapper in Boost.Python.
We talked about different shortcomings with the existing "numeric"
module, and why a richer API to access NumPy would be useful.
Some code to address these shortcomings already exists, and may be used
as a starting point for such Boost.Python improvements.
Anyone considering to work on this, please get in touch !
I would definitely like to be involved in this, and I can provide a lot
of that "existing code". I'm not sure I can sign up as a full mentor at
this point - I have a PhD thesis to write this summer that needs to take
priority - but I'd certainly like to help.
Jim Bosch
I am very interested in Jim's code, which I've just started using. Previously,
I have used pyublas extensively and found it very capable. But Jim's ndarray
code adds a lot of functionality.
While I appreciate others wanting to get involved, this is a battle that has
dragged on for years. I doubt that even a brilliant newcomer can create
something even approaching pyublas or ndarray in one summer.
I only have 3 concerns regarding ndarray at present:
1) documentation is thin
2) not sure about efficiency of various usage patterns
3) not sure about future support
On a side note, I'm wondering if the new iterator in numpy-1.6 will be helpful.
Neil, I certainly appreciate (and agree with) the viewpoint that all of
this can't be done in one summer by a relative newcomer.
But I think we can put together reasonable GSoC project by limiting our
attention to cleaning up and completing the boost/python/numpy code,
rather than deal with the entire ndarray package (I think this is what
Stefan had in mind, anyhow). If we can get that in a state where it can
be added to Boost.Python (even if it's an optional build target),
ndarray can simply be upgraded to make use of that rather than what's in
the boost sandbox. And hopefully other projects that don't want to use
ndarray (like pyublas) will can use boost/python/numpy at a lower level
as well.
If we start with boost/python/numpy, I think the most important tasks are:
- Add "object manager" classes for additional numpy types ("object
managers" are Boost.Python versions of Python types; right now
boost/python/numpy only supports the most important numpy types, like
numpy.ndarray and numpy.dtype). Most of these will be trivial, but
there may be a lot of them. We want complete coverage of the numpy C-API.
- Add additional methods to the numpy.ndarray object manager
(numpy.ndarray has a ton of methods in Python; I'm not sure all of them
need to be supported from C++ if we can do attr("method")())
- Fix conversions between numpy scalar types and C++ POD types (other
projects mentioned on this list have solved this at some level).
- Review and possibly revise the array-from-data API (i.e. how should
the user pass in shape and strides?)
- Review and possibly revise how the numpy C-API and its ugly
preprocessor macros are hidden.
- Add documentation.
- Integrate into the boost build system.
Jim
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
