[C++-sig] GSoC Boost.Python project

Jim Bosch talljimbo at gmail.com
Thu Mar 31 05:14:49 CEST 2011


On 03/30/2011 08:01 PM, Ankit Daftery wrote:
> Hello
>
> I am working on the project proposal for GSoC 2011 for the Boost.python
> project, and I would like a little help.
>
> 1.  ndarray.hpp mentions that functionality needs to be added like the
> one in boost::python::numeric::array . Stefan suggested that Jim might
> be able to help with what exactly was intended. Is there anything
> specific in mind ?

If one looks at the Numpy C-API or the list of methods available to 
numpy.ndarray, there are a lot more than are present in the wrapper in 
ndarray.hpp.  Some of these should be added to ndarray.hpp.

>
> 2. Neal mentions that efficiency needs to be improved. Could you please
> help me with a little more detail about that, Neal ?
>
> 3. ndarray.hpp also mentions that the templates "Should probably take
> ranges of iterators rather than actual container objects." Could someone
> explain what is intended ?
>

This is just a question of how best to pass a sequence of integers that 
specify the shape and stride of array.  Making the argument a specific 
C++ container type requires the user to use exactly that type and to 
fill it with exactly those elements; it's usually considered better form 
to accept a range of iterators when you can.  Taking iterator ranges 
makes for a lot of arguments, though, which makes the API a little 
unwieldy, especially considering the size of the containers has to be 
the same.

I think one of the goals for the GSoC project would be to look at 
different ways to rework that API and see what various people like best.

> Am I missing out on something essential ? Anything I should keep in mind
> ? Tips and pointers.

In one of my previous emails on this list I wrote down what my goals 
would be for this project (including the two discussed above).  In 
general, I think it's about taking the sandbox library and cleaning it 
up to the point where it's at a boost level of quality, and possibly 
revisiting some of the design decisions that went into it.

Jim




More information about the Cplusplus-sig mailing list