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 usually avoided enhancements over standard ndarray, but I think xarray [1] makes a good case, in combining both Pandas like convenience with labeled dimensions. Specifically, it seems like a step forward in making it easy to write correct code, especially when we might want it to be agnostic to layout. A trivial example is summing over time: with a plain array, you have to know which axis is time, then it's data.sum(axis=time_axis), whereas a labeled array knows that for you, so it's just data.sum('time'). It also helps coordinate work between multiple arrays sharing one or more axes, see [1] for more.
The plain, typed alternative is to write a full wrapping class around every data type, and operations for all their interactions, but this is a lot of boilerplate code for the classes themselves and the tests.
I usually avoided enhancements over standard
ndarray
, but I think xarray [1] makes a good case, in combining both Pandas like convenience with labeled dimensions. Specifically, it seems like a step forward in making it easy to write correct code, especially when we might want it to be agnostic to layout. A trivial example is summing over time: with a plain array, you have to know which axis is time, then it'sdata.sum(axis=time_axis)
, whereas a labeled array knows that for you, so it's justdata.sum('time')
. It also helps coordinate work between multiple arrays sharing one or more axes, see [1] for more.The plain, typed alternative is to write a full wrapping class around every data type, and operations for all their interactions, but this is a lot of boilerplate code for the classes themselves and the tests.
[1] http://xarray.pydata.org/en/stable/why-xarray.html
The text was updated successfully, but these errors were encountered: