-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider generalizing backends of array APIs #98
Comments
Thanks a lot @diegoferigo! <3 |
Yep I agree! If there is interest in merging at least the remaining ones by exploiting |
I remember a f2f discussion a while ago with @Giulero about how to generalize algorithms to work on NumPy / JAX / PyTorch etc. At that time, there was no concrete solution excluding what today became
Farama-Foundation/Jumpy
that was only supporting NumPy and JAX.After a couple of years, it seems that the community is trying to address this use case with the Python array API standard. It seems that this solution is the one that got major traction and attracted most of the interest towards this unification.
ADAM, today, generalizes the underlying array APIs used by the RBDAs by introducing a custom abstraction layer based on
adam.core.spatial_math.{ArrayLike|ArrayLikeFactory|SpatialMath}
, which has implementations in CasADi, JAX, NumPy, and PyTorch.I think that CasADi --at least in the short term and at least officially-- won't be compatible with these Array APIs. However, providing in ADAM a new backend based on these new APIs could ease the maintenance of the other backends (or, possibly remove them), and could bring with no additional effort also support for all other array providers that are adhere with the API standard.
A good starting point could be the
data-apis/array-api-compat
wrapper1, its usage seems pretty straightforward.Footnotes
https://data-apis.org/array-api-compat/ ↩
The text was updated successfully, but these errors were encountered: