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 have just begun to use zarr and it is great thank you!
The one thing I find mildly annoying is having to write oindex and vindex when doing advanced slicing. This is because I am writing functions that can handle either an in memory numpy array or a zarr.core.Array. So a lot of code ends up looking like
if type(x) == zarr.core.Array:
# slice with oindex or vindex
else:
# slice with numpy
whenever the slice involves advanced indexing.
It seems like all the support is already there just hiding behind different names. It would be great if such checks were not necessary and if slicing matched numpy API, both semantically and syntactically. It looks to me that the semantic part is already done, part of oindex functionality is even beyond that of numpy slicing, doing something that I typically use two slices for, but that could just stay as part of oindex.
Exact correspondence with numpy slicing could be a great selling point for zarr I think, and doesn't seem like a huge lift given that the semantics are already supported and the change seems like it would be backwards compatible (Although of course I could be very wrong about that as I don't know all the intricacies involved)
Also as far as I can tell oindex support boolean indexing as well but that is not documented.
The text was updated successfully, but these errors were encountered:
@Ha5hBr0wn: it would be great if you could try out a later version of Zarr (like the current 2.13) and see if it does what you need. I'm going to go ahead and close this issue because as @jakirkham says, some of this has been implemented. If you can give us an example of any additional advanced indexing you need in a new issue, that'd be great.
Hi,
I have just begun to use
zarr
and it is great thank you!The one thing I find mildly annoying is having to write
oindex
andvindex
when doing advanced slicing. This is because I am writing functions that can handle either an in memorynumpy
array or azarr.core.Array
. So a lot of code ends up looking likewhenever the slice involves advanced indexing.
It seems like all the support is already there just hiding behind different names. It would be great if such checks were not necessary and if slicing matched
numpy
API, both semantically and syntactically. It looks to me that the semantic part is already done, part ofoindex
functionality is even beyond that ofnumpy
slicing, doing something that I typically use two slices for, but that could just stay as part ofoindex
.Exact correspondence with
numpy
slicing could be a great selling point forzarr
I think, and doesn't seem like a huge lift given that the semantics are already supported and the change seems like it would be backwards compatible (Although of course I could be very wrong about that as I don't know all the intricacies involved)Also as far as I can tell
oindex
support boolean indexing as well but that is not documented.The text was updated successfully, but these errors were encountered: