[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