Open hmaarrfk opened 2 months ago
In the lines above, there seems to be a desire to keep the array "writable" (that won't work in our arrays, they are read-only anyway)
This desire is because we call broadcast
under the hood in many places, and it can get quite surprising when arrays are suddenly read-only.
indexer = (None,) * (len(expanded_dims) - self.ndim) + (...,)
Looks like this is supported by array API indexing rules so your proposal sounds good to me.
Each None in the selection tuple must expand the dimensions of the resulting selection by one dimension of size 1. The position of the added dimension must be the same as the position of None in the selection tuple.
ok thanks, i'll try to think of a test to add and to do this PR. We ultimately work around issues like this, but I appreciate the thought put into answering all the questions we have.
Is your feature request related to a problem?
Our duck arrays got caught by
duck_array_ops.broadcast_to
https://github.com/pydata/xarray/blob/0af197985840a715c3566b6bdb5f355b21224e92/xarray/core/variable.py#L1382really boiling down to
np.broadcast_to
since we don't implement it quite yet.In the lines above, there seems to be a desire to keep the array "writable" (that won't work in our arrays, they are read-only anyway), but there is an other case where the underlying array stays writable, and that is when new dimensions of "1" get added.
Describe the solution you'd like
New dimensions of 1 to be inserted via slicing
np.newaxis
I thinke the code could be refactored to be
effectively just flipping the "else" and and the "elif"
Describe alternatives you've considered
Manually broadcasting the DataArrays prior to the call to
xr.expand_dims
Additional context