Timeline for sharing memory between Eigen and NumPy

[jcarpent]

I've implemented the complete share of memory between Eigen and Numpy without requiring any memory copy or allocation. I will suggest it as PR soon.

In the meantime, we need to decide in a similar way as #87 when to achieve the official switch.

[gabrielebndn]

Hallo! News about this?

[gabrielebndn]

Why is a timeline needed? What would the problem be if we integrated it right now? I do not think any existing Python code would be broken or would modify its behavior if this change is integrated

[jcarpent]

Yes, it will. Because when you write something like:

R = data.oMi[joint_id]
R[0,0] = 2.

it will mean the memory will change also in data. And a lot of people are doing this kind of stuff!

[gabrielebndn]

Yes, it will. Because when you write something like:

R = data.oMi[joint_id]
R[0,0] = 2.

it will mean the memory will change also in data. And a lot of people are doing this kind of stuff!

I see. But I think that mostly concerns Pinocchio, not eigenpy. The point is, in order to make it work, we are forced to explicitly write in our bindings that we want a copy to be made. That is what is being done in Pinocchio. So, if you do include this change in eigenpy, then it will be a matter for Pinocchio to make the switch so to make productive use of this new possibility.
Am I wrong?

[jcarpent]

No, but you might be aware that currently, I do not have so much to perform both transistions on EigenPy and Pinocchio.

[gabrielebndn]

No, but you might be aware that currently, I do not have so much to perform both transistions on EigenPy and Pinocchio.

You do not have so much time, you mean?
Maybe you can do it just on eigenpy, so that we can use the new feature in things like hpp-fcl and curves. What other libraries are using eigenpy?

[jcarpent]

Yes, I do not have time right now.

[jcarpent]

I will try this week, but I'm not sure I will be able to make it.

[jcarpent]

By the way, this missing feature should not block you on making bindings for hpp-fcl and others.

[gabrielebndn]

By the way, this missing feature should not block you on making bindings for hpp-fcl and others.

It does not ;) It's just that I stumbled into this while working on it and I thought it would be nice to solve the problem once and for all

[jcarpent]

Yes, I do agree. But, you know, a lot of things missing are mainly a matter of time.

[cmastalli]

It would definitely important for Crocoddyl. It would great if we can find a fast solution that doesn't affect Pinocchio users, and we can soon integrate to Crocoddyl.

On the other hand, it should be ok that this operation changes the memory, this is what everyone expect. If someone has such kind of Python code and doesn't expect change in data, then he/she should make a copy. This is Python good coding practice. Why should we care of wrong practice?

[wxmerkt]

I am all for the change and pybind11 supported it from the get-go.

However:

Why should we care of wrong practice?

Because it breaks existing code "silently" (and good luck tracking those bugs down if you do not follow the eigenpy repository and all related discussions and the update comes with an apt-get....) that followed the existing convention (without .copy()) and worked just fine. To be clear: I don't have any code that may break but this kind of change can easily throw users into debugging hell.