issue_comments

Another challenge with changing the meaning of slice is handling partial slices, e.g., what does slice(500, None) mean? With a monotonic decreasing index, that would select values below 500, but ignoring underlying coordinate order it would presumably mean selecting values above 500.

I think the separate new API (e.g., xarray.Between or .sel_between()) is probably a better idea.

One complication with using sel() with slice objects is that you can do selection over non-monotonic indexes, merely based on matching bounds: ```

data = xarray.DataArray([1, 2, 3, 4, 5], dims=['x'], coords=[[5, 1, 4, 3, 2]]) data <xarray.DataArray (x: 5)> array([1, 2, 3, 4, 5]) Coordinates: * x (x) int64 5 1 4 3 2 data.sel(x=slice(1, 3))) <xarray.DataArray (x: 3)> array([2, 3, 4]) Coordinates: * x (x) int64 1 4 3 ```

If we change the semantics of slice in sel() to do filtering rather than be concerned about order (which does seem much less useful), we should probably deprecate the handling of non-monotonic ascending or descending indexes.

Alternatively, we could either do the dedicated indexing object like xarray.Between(lower, upper) or have a dedicated method for selecting between values, e.g., perhaps data.sel_between(x=(1, 3)) or data.sel_bounds(x=(1, 3)).

What would be a good solution? 1. Make sel implicitly ignore order for slice objects. 2. Add a option to sel for explicitly ignoring slice order. 1. add a new kwarg 2. Add a new xr.Between object

This is probably worth fixing if possible in a straightforward way. I don't think anyone is well served by matching the behavior of Python list indexing here -- it's a strange edge that case that indexing a list like x[5:0] returns an empty list.

Making slice(high, low) return the same as slice(low, high) on a monotonic increasing index seems reasonable.

Agreed, I don't think many pandas users would object to this.

there is standard geo software (looking at you ArcGIS) that can write geoTiff's with monotonic decreasing indices

This is very frequent for climate models also (lat arrays are frequently upside down). An xarray (or upstream) solution would be very useful indeed, but possibly there are other things to consider, like being "too magical".

xarray makes a very good job at handling decreasing coordinates (i.e. when plotting), but soon or late users might need to know how they data is ordered, and indexing might be the right time to warn them about it when they do something wrong: usually an empty array is unlikely to be left unnoticed, so that the current behavior might help to find bugs in user code.

Additionally: arguably monotonicity should not be required. When one uses labels, the semantics are clear without monotonicity.

Requiring monotonicity lets us guarantee that the result is a NumPy view rather than possibly being a copy.

Consider using index.is_monotonic_ascending and index.is_monotonic_descending instead of subtracting the first few values -- those are exactly the checks that pandas uses.

I also did a little more searching and found that this has come up in the xarray issue tracker before: https://github.com/pydata/xarray/issues/1465

Thinking about this a little more, I'm remembering the reasoning for pandas working this way:

1. Integer slicing by position and by label with positive integers should work the same for an index with values given by range(N).
2. Positional indexing in Python x[a:b] returns all values between a and b in order. Indexing like x[high:low] with high > low returns an empty list.
3. Label based indexing in pandas has df.loc[df.index[i] : df.index[j]] equivalent to df.iloc[i : j+1] (arguably this is a mistake; e.g., https://github.com/pydata/xarray/issues/1492 and other discussion that I can't find right now :) ).
4. Indexing a monotonic decreasing index therefore should work for decreasing labels.
5. If slicing a monotonic increasing index only works for increasing but not decreasing labels, then it would be weird if indexing a monotonic decreasing index works for both increasing and decreasing labels.

To clarify: xarray behavior doesn't just mirror pandas here -- it actually directly uses pandas to figure out the mapping from labeled slices to integer slices.

So I'm not opposed to changing this (I agree this trips people up often) but we should try to change it upstream if possible.

This was actually intentional, though you are certainly not the first person to complain about this.

Xarray's behavior mirrors pandas. The justification for this logic is that sel/loc would work like normal indexing [] on a Python list, and if you supply slice limits in the opposite order on a Python list, you get an empty result.

Probably the cleanest solution possible would be a separate selection object for xarray that doesn't care about order, e.g., da.sel(x=xarray.Between(10, 50)).