David Cournapeau wrote:
Matthieu Brucher wrote:
scipy does certainly not depend on Boost. Blitz is used in weave, but I don't know if this is mandatory (and it includes the blitz library); I think that actually, a C++ compiler is not even mandatory. Maybe I am missing something, but why the need for a matrix library for basic neighbors algorithm ?
That's right, I do not have the utility for a fully-fludged matrix library, but basic stuff yes. For a neighbooring algorithm, I can use basic computations, norms, ... Yes, I could program them directly, but if there is already something in scipy, no use to do it again ;)
I don't think there is anything like that in scipy. Something which could be useful would be to have a C++ class which reflects a numpy array, for seamless integration between eg boost.python and numpy. But that would be quite a challenge to get it right, I think.
David
There is numerical interface in boost::python. I don't use this approach myself. Here's why. I write all basic algorithms in c++. I try to use modern, generic programming when writing them. There is AFAIK, no reasonable way to interface such code to numerical/numpy. The C interface to numpy is too low-level. IOW, I like writing in c++, and I don't want to have to write code at such a low-level interface as would be needed to interface to numpy. So my approach is: 1. Write c++ algorithms with generic interfaces (where feasible). 2. When it is not feasible to use generic container types, I use boost::ublas::{vector/matrix} explicitly. 3. The above c++ code is parametrized (templated) on the container types. 4. Explicit instantiations of (3) are then exposed to python, normally specifying ublas::{vector/matrix} as the input/output types. This doesn't, of course, directly interoperate with numpy. I can, however, convert between numpy arrays and ublas::matrix (which currently requires copying the data, unfortunately).