hailiangzhang

Ah, probably this is not very surprising based on the notes you provided:) So, in this case, I can [add the testing to my PR as we originally planned](https://github.com/zarr-developers/zarr-python/pull/1014#issuecomment-1115230278). In...

@jakirkham , agreed (and that's actually what I would imagine:) Since `resize` actually deletes data at chunk level of resolution, this could be a little bit unexpected by the end...

> 👍 for the doc improvement. I've updated the title of this issue to: > > * `resize(): Improve docs & control of what is modified` > > with the...

Hi, since my PR has been merged, feel free to close this ticket (and please let me know if I am supposed to do that:)

Thanks a lot for your very detailed update @christine-e-smit ! Christine has a very good comment on the performance concern when the maximum number of dimensions is very large (since...

> Super interesting thread - it looks like we never published checksums in CMR at GES DISC but we have records of that internally and validate using checksums our migration...

> Thanks for this proposal. It seems like it may make sense to specify the stride in units of elements rather than chunks. Then this would more generally also cover...

> @hailiangzhang As I mentioned at the meeting today, it would be very helpful if you can provide some mathematical formulas or pseudocode that describes which cumulative sums you are...

> Independent of these details, I think it is clear now that this exists as an additional layer entirely on top of zarr itself. I'm still interested in learning more...

Thanks for your responses @rabernat and @jbms ! Actually this proposal is probably comparable to the approach used in the Xarray library, which introduces specific fields such as _ARRAY_DIMENSIONS within...