You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I suspect the ergonomics could be improved (or better documented) in the ndarray crate, but since this might be a more common pain point for new users of rust-numpy (compared to people just learning ndarray in isolation), I thought I'd mention it here as well.
New users of the ndarray crate are probably going to start out with owned arrays of static number of dimensions, whereas a numpy users starting from the rust-numpy example get handed an array of dynamic dimensions and non-owned data with lifetime bound to the python interpreter. I imagine that would be nice for performance if we ever manage to get our code to compile, but for a numpy user trying to get up to speed in rust, it really throws you into the deep end of the pool.
Thanks!
The text was updated successfully, but these errors were encountered:
We're experiencing a lot of friction just figuring out how to get our data all of the way out of a pyarray.
rust-ndarray/ndarray#493
I suspect the ergonomics could be improved (or better documented) in the ndarray crate, but since this might be a more common pain point for new users of rust-numpy (compared to people just learning ndarray in isolation), I thought I'd mention it here as well.
New users of the ndarray crate are probably going to start out with owned arrays of static number of dimensions, whereas a numpy users starting from the rust-numpy example get handed an array of dynamic dimensions and non-owned data with lifetime bound to the python interpreter. I imagine that would be nice for performance if we ever manage to get our code to compile, but for a numpy user trying to get up to speed in rust, it really throws you into the deep end of the pool.
Thanks!
The text was updated successfully, but these errors were encountered: