Christopher Barker wrote: > Michael Droettboom wrote: > >> It's funny you should mention this. >> >> One of the things I realized after SciPy this year is that there is a >> lot of interfacing of Numpy with C++ (as opposed to C) that could really >> benefit from a standard C++ wrapper around Numpy. >> > > Absolutely. Though now that you mention it, isn't there one in > boost::python? or at least one that worked with Numeric. > > Yes, but AFAICT it forces the use of boost::python, at least to convert the object. It would be nicer (in some cases) to have something that could be wrapper-system-agnostic. I spent a little time working on this today, and I was actually pleasantly surprised by how far I got. I have something that exposes Numpy arrays as boost::multi_arrays on the C++ side, and also allows for creating new Numpy-backed arrays from C++. The memory is still managed with Python reference counting, and the references are automatically freed from the constructor. It requires boost and Numpy, of course, but not boost::python. A standalone C++ class for this would perhaps have been nicer, but that's not an afternoon's 200-line hack like this is. I wouldn't really consider this a "wrapper" around Numpy, since it doesn't actually use Numpy for any of the indexing or computation. It simply converts the Numpy description (pointer + strides, etc.) to a boost::multi_array, without copying the underlying data. > >> projects all had home-grown, semi-complete solutions. >> A standard wrapper would be good for all of the reasons you mention >> (basically resource management), but also to have a cleaner syntax for >> accessing the elements that would abstract away striding, ordering etc. >> > > I think I'm thinking of something slightly different. What I'd like is > set of array classes that can interface well with numpy, and also be > quite usable all by themselves in C++ code that has nothing to do with > python. > This should fit that bill. Just templatize all your algorithms to accept anything with the "boost::multi_array" interface. When building extensions for Numpy, pass in a wrapped numpy array -- when not, use a pure boost::multi_array. Of course, the pure boost::multi_array doesn't have reference-counted memory management. Use of boost::shared_ptr may help, but it's not "built-in" -- views of boost::multi_arrays don't automatically keep their parent data alive. It's the usual C++ "you're on your own" approach. > I don't really envision a C++ ndarray -- I generally think of C++ as > static enough that I'm happy to define that I need, for example, a NX2 > array of doubles. I don't see using a generic array like ndarray that > could hold any type, shape, etc. But maybe others do -- it would be > pretty cool. > My approach (being based on boost::multi_array) has a fixed type and number of dimensions at compile time. If you try to pass in a Numpy array that can't be converted to that, an exception is thrown. Personally, I feel that's good enough for most domain-specific algorithms. Theoretically, one could write algorithms that are templatized on the data type and then dispatch at run time to different instantiations of that template -- but my code doesn't do anything like that yet. > I guess to some extent the question is whether you are writing > extensions for python, or a C++ that you want to use from C++, and also > wrap for python. > I'm just doing this out of curiosity rather than to meet a need. We don't have much C++ code at the Institute. I could see this being very handy in matplotlib, however, but the dependency on Boost is probably a showstopper... :( > But maybe both need can be met by the same C++ classes (templates?) > I think so. See above. > >> It may actually be possible to build it around boost::multiarray >> > > Do you know off hand if multiarray can be constructed from an existing > pointer to a data block? > Yep. multi_array_ref seems custom-built for that purpose. > >> Can't imagine I'll find time for it anytime soon, >> I went ahead and created a Google Code project for this here: http://code.google.com/p/numpy-boost/ Just because it's up there doesn't mean it's anything more than an experimental hack. It needs documentation and more complete unit tests... etc... Mike