personalrobotics / boost_numpy_eigen Goto Github PK

Hi!

It seems that https://github.com/ndarray/Boost.NumPy is deprecated,
as NumPy support is now natively supported by Boost.Python.

Do you have any plans to update this library accordingly?

Hello!
I'm having troubles to export data structures that contain eigen members.

Example
This is a minimal example of what I would be able to do, but doesn't work.
Suppose that I have a struct like this:

struct Foo {
    int a;
    Eigen::Vector3d b;
};

I export it:

BOOST_PYTHON_MODULE(libhello) {
  SetupEigenConverters();

  class_<Foo>("Foo", init<>())
    .def_readonly("a", &Foo::a)
    .def_readonly("b", &Foo::b)
  ;
}

Then I try to work with it in Python:

import libhello
foo = libhello.Foo()
print(foo.b)

Unfortunately, I get an error like this:

TypeError: No Python class registered for C++ class Eigen::Matrix<double, 3, 1, 0, 3, 1>

Another example
This example works, but it is not exactly what I want.

struct Foo {
    int a;
    Eigen::Vector3e b;
    Eigen::Vector3d getB(void) { return b; }
};

class_<Foo>("Foo", init<>())
    .def_readonly("a", &Foo::a)
    .add_property("b", &Foo::getB)    // <- note the explicit getter
  ;

What is the issue?
These are just minimal examples, but in a real use case I have a complex hierarchy of classes. If I were to define an explicit getter for each attribute, then the complexity would easily explode. I don't really understand why I get the above error, the class should be already defined, no? If not, then why do the methods that directly return an eigen type work?

I realized recently that the way I implemented the conversion might not be quite logically correct.

I was guided by the principle: "in conversion from numpy array to Eigen Tensor, the indexing with the same subscripts should remain the same".

This rule would basically mean that tensor_as_numpy_array[1,2,3] and tensor_as_Eigen_Tensor(1,2,3) should be the same.

This rule tends to hold alright for the Eigen matrices, which are column-major but are indexed in a row-major fashion, i.e. eigen_tensor(2,3) means "row 2, column 3". I guess Eigen developers noticed they cannot contain the inconsistency between actual layout and indexing scheme beyond 2 dimensions, so the Tensors are actually indexed and stored consistently, as evidenced by the following statement:

By default, Tensors are stored in "column-major" order, &t(x+1, ...) == &t(x, ...) + 1, &t(x, y+1, ...) == &t(x, y, ...) + t.dimension(0), etc.

So, it might make more sense to convert fully without reversing axis order (the way I did it originally).
In this case, entries tensor_as_numpy_array[1,2,3] and tensor_as_Eigen_Tensor(3,2,1) should be the same.So, the last axis is (and should be) most significant in Eigen and the first axis is (and should be) the most significant axis in numpy. Preserving correspondence of the data ordering may is not only important to avoid unnecessary operations (axis swapping) during the conversion, but also important to be better able to optimize code that depends on traversing axes in least-to-most-significant way.

Please let me know what you think and I can alter the design accordingly.