Christopher Barker wrote:
> Alexander Schmolck wrote:
>> I just saw a closely related question posted one
>> week ago here (albeit mostly from a swig context).
>
> SWIG, Boost, whatever, the issues are similar. I guess what I'd love to
> find is an array implementation that plays well with modern C++, and
> also numpy.
>
Maybe I am naive, but I think a worthy goal would be a minimal C++
library which wraps ndarray, without thinking about SWIG, boost and co
first. I don't know what other people are looking for, but for me, the
interesting things with using C++ for ndarrays would be (in this order
of importance):
1 much less error prone memory management
2 a bit more high level than plain C ndarrays (syntactic sugar
mostly: keyword args, overloaded methods and so on)
3 more high level things for views
4 actual computation (linear algebra, SVD, etc...)
1 and 2 can "easily" be implemented without anything but plain C++. 3
would be a pain to do right without e.g boost::multiarray; 4 obviously
needs external libraries anyway. My guess is that most people need
mostly those 4 points, but not in the same order. Am I right ?
One huge advantage of being independant of external libraries would be
that the wrapper could then be included in numpy, and you could expect
it everywhere.
>
> I guess what I'd like is a C++ array that was essentially an ndarray
> without the pyobject stuff -- it could then be useful for C++, but also
> easy to go back and forth between numpy and C++.
>
> Ideally, there'd be something that already fits that bill. I see a
> couple design issues that are key:
>
> "View" semantics: numpy arrays have the idea of "views" of data built in
> to them -- a given array can have it's own data block, or a be a view
> onto another. This is quite powerful and flexible, and can save a lot a
> data copying. The STL containers don't seem to have that concept at all.
> std::valarray has utility classes that are views of a valarray, but they
> really only useful as temporaries - they are not full-blown valarrays.
What do you mean by STL does not have the concept of view ? Do you mean
vector ?
>
> It looks like boost::multiarrays have a similar concept though
> """
> The MultiArray concept defines an interface to hierarchically nested
> containers. It specifies operations for accessing elements, traversing
> containers, and creating views of array data.
> """
>
> Another issue is dynamic typing. Templates provide a way to do generic
> programming, but it's only generic at the code level. At compile time,
> types are fixed, so you have a valarray<double>, for instance. numpy
> arrays, on the other hand are of only one type - with the data type
> specified as meta-data essentially. I don't know what mismatch this may
> cause, but it's a pretty different way to structure things. (Side note:
> I used this feature once to re-type an array in place, using the same
> data block -- it was a nifty hack used to unpack an odd binary format).
> Would it make sense to use this approach in C++? I suspect not -- all
> your computational code would have to deal with it.
Why not making one non template class, and having all the work done
inside the class instead ?
class ndarray {
private:
ndarray_imp<double> a;
};
>
> There is also the re-sizing issue. It's pretty handy to be able to
> re-size arrays -- but then the data pointer can change, making it pretty
> impossible to share the data. Maybe it would be helpful to have a
> pointer-to-a-pointer instead, so that the shared pointer wouldn't
> change. However, there could be uglyness with the pointer changing while
> some other view is working with it.
If you have an array with several views on it, why not just enforcing
that the block data address cannot change as long as you have a view ?
This should not be too complicated, right ? I don't use views that much
myself in numpy (other than implicetely, of course), so I may missing
something important here
cheers,
David
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
