expose operators through cython

[Matthew Broadway]

Currently no operators are exposed through the cython wrapper for example:

operator*()  --> __mul__()
operator+() --> __add__()
operator-() --> __sub__()
size()  --> __len__()
equals() --> __eq__() and __ne__()
operator[]() --> __getitem__() and __setitem__()

And possibly, if a class has both size() and at() or operator[]() then __iter__() could be defined which would allow for writing for loops like for item in container: (but only if indices are contiguous)

For python 3, the matrix multiplication operator A @ B could also be defined for any appropriate classes with __matmul__() and __rmatmul__()

Some of these operators are 'nice to have' whereas some are quite important, like being able to do Point3() + Point3()

[Frank Dellaert]

@thduynguyen and I are working behind the scenes to switch the python wrapper to pybind11. I think it will be much easier to support operators there. Another ambition in that project is to completely erase the difference between point3 and numpy vectors. The thing that holds us back there is MATLAB, actually.

[Eric Cousineau]

Would completely understand if you decide to keep things as-is, but you may want to consider deprecating __mul__ / operator* for anything that has an operator* that doesn't relate well to array multiplication, and only use __matmul__ (esp. with the End-of-Life announcement of Python 2, slated for 2020-01-01).

In this way, it "forces" people keep funky numpy semantics in mind; as an example for poses:

A * B with Pose3 is excellent; A * B with np.array gives you garbled nonsense.

A @ B will always give you the right value, regardless of the types (assuming correct type promotion).

[Frank Dellaert]

Excellent point

[Frank Dellaert]

gtsam 5 feature request