html_url,issue_url,id,node_id,user,created_at,updated_at,author_association,body,reactions,performed_via_github_app,issue
https://github.com/pydata/xarray/issues/5648#issuecomment-925025457,https://api.github.com/repos/pydata/xarray/issues/5648,925025457,IC_kwDOAMm_X843IsSx,98330,2021-09-22T15:12:14Z,2021-09-22T19:25:49Z,NONE,"There are also some relevant and very interesting PyTorch development discussions; there are a lot of Tensor subclasses in the making and thought being put into how those interact:
- https://dev-discuss.pytorch.org/t/state-of-pytorch-core-september-2021-edition/332#alternative-tensors-5
- https://pytorch-dev-podcast.simplecast.com/episodes/tensor-subclasses-and-liskov-substitution-principle
- https://dev-discuss.pytorch.org/t/functorch-levels-as-dynamically-allocated-classes/294","{""total_count"": 2, ""+1"": 2, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,956103236
https://github.com/pydata/xarray/issues/5648#issuecomment-890310954,https://api.github.com/repos/pydata/xarray/issues/5648,890310954,IC_kwDOAMm_X841EREq,98330,2021-07-31T08:24:02Z,2021-07-31T08:24:02Z,NONE,"> Interesting - could you say a bit more? Looking at these two issues, it seemed more like the question was simply on hold until someone who wanted it badly enough came along?
There is a significant backwards compatibility break when a library adds `__array_ufunc__` and `__array_function__`. JAX maintainers were not comfortable with that. @shoyer wrote https://numpy.org/neps/nep-0037-array-module.html as a follow-up largely because of that. That NEP is effectively superceded by the array API standard (https://data-apis.org/array-api/latest/ and NEP 47). PyTorch has decided to adopt that and implementation is well underway. Experimental support in NumPy will land next week (complete except for `linalg`). CuPy and MXNet plan to follow that NumPy implementation. JAX and Dask not yet decided I believe, but likely to follow NumPy as well.
> Canonical/minimal API of a ""duck array"" and how to detect it (though may be superseded by NEPs 30 and 47 among others)
This is basically what the array API standard provides (most functions follow NumPy, with deviations mostly where other libraries were already deviating because they could implement something on GPU, with a JIT, or with a non-strided memory model). `__array_function__` has worked quite well for CuPy and Dask, because they follow the NumPy API almost to the letter, with only a couple of exceptions (e.g. 0-D array instead of array scalars in CuPy). JAX, PyTorch and MXNet all deviate much more, and since the NumPy API is not very well-defined (there's 1500+ public objects plus more semi-public ones), you'd have no guarantees about what works and what doesn't.
That said, `__array_ufunc__` and `__array_function__` aren't going anywhere. The RAPIDS ecosystem is invested in it and I believe largely happy with it. So adding Xarray and Pint to the mix sounds potentially interesting.","{""total_count"": 2, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 1}",,956103236
https://github.com/pydata/xarray/issues/5648#issuecomment-889875756,https://api.github.com/repos/pydata/xarray/issues/5648,889875756,IC_kwDOAMm_X841Cm0s,98330,2021-07-30T12:59:04Z,2021-07-30T12:59:04Z,NONE,"I'm happy to join, seems interesting. And yes, I can say something about PyTorch. There probably isn't much to say though - PyTorch is unlikely to adopt `__array_function__` at this point, just like JAX. And it doesn't seem critical for this hierarchy anyway - the fundamental array objects (PyTorch/CuPy/NumPy/Sparse/JAX arrays or tensors) do not have or need a class hierarchy, they are all at the bottom and should not be mixed.
The key thing here seems to be Dask <-> Xarray <-> Pint, unless I'm missing something?","{""total_count"": 2, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 1, ""rocket"": 0, ""eyes"": 0}",,956103236