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
We could change xindexview to work with vectors of indices instead of a vector of xindex, as numpy does. I.e. instead of taking std::vector<xindex>, we could take a number of xt::xarray<size_t> vectors, one per dimension.
Then, when resolving to the index, we just have to multiply with the corresponding stride, which should be fast in e.g. the assignment loop.
We could also store the offsets instead of the vectors, and calculate a shape and reuse the xstridedview to also resolve cases where the number of supplied vectors is lower than the dimension.
However, it feels that this would come at a cost for the case where scalar elements are selected.
The text was updated successfully, but these errors were encountered:
We could change xindexview to work with vectors of indices instead of a vector of
xindex
, as numpy does. I.e. instead of takingstd::vector<xindex>
, we could take a number ofxt::xarray<size_t>
vectors, one per dimension.Then, when resolving to the index, we just have to multiply with the corresponding stride, which should be fast in e.g. the assignment loop.
We could also store the offsets instead of the vectors, and calculate a shape and reuse the xstridedview to also resolve cases where the number of supplied vectors is lower than the dimension.
However, it feels that this would come at a cost for the case where scalar elements are selected.
The text was updated successfully, but these errors were encountered: