issue_comments

Shall we raise a warning in where advising the more-efficient syntax? Or shall we skip the call to where_method

I'm not sure that either of these is a good idea.

The problem with raising a warning is that this is well-defined behavior. It may not always be useful, but well defined but useless behavior arises all the time in programs, so it's annoying to raise a warning for a special case.

The problem with skipping where_method is that now we end up with a potentially inconsistent dtype, depending on the selection. These sort of special cases can be quite frustrating to program around.

It seems rather unlikely to me to have an example of where with drop=True where the condition is exactly aligned with the grid, such that there are no missing values.

Actually, this is a really common pattern python ds = xr.tutorial.open_dataset('air_temperature') ds.where(ds.time.dt.hour.isin([0, 12]), drop=True)

The efficient way to do this is python ds.loc[{"time": ds.time.dt.hour.isin([0, 12])}] or

python ds.sel(time=ds.time.dt.hour.isin([0, 12]))

At this point https://github.com/pydata/xarray/blob/48378c4b11c5c2672ff91396d4284743165b4fbe/xarray/core/common.py#L1270-L1273

cond is all True and applying where is basically a totally useless copy since the isel has already copied.

Shall we raise a warning in where advising the more-efficient syntax? Or shall we skip the call to where_method

What about the case of no missing values, when other wouldn't be needed? Could the same dtype be returned then? This is my case, since I'm re-purposing where to do sel for non-dimension coordinates.

Could you give a concrete example of what this would look like?

It seems rather unlikely to me to have an example of where with drop=True where the condition is exactly aligned with the grid, such that there are no missing values.

I guess it could happen if you're trying to index out exactly one element along a dimension?

That's exactly right. I am just selecting one slice of a data array, using data.where(data.coords['stain'] == 'DAPI').

In the long term, the cleaner solution for this will be some form for support for more flexibly / multi-dimensional indexing.

Agreed. Once I actually get things running, I'll be ready to try and contribute fixes for all my TODOs that reference xarray github issues. :)

What about the case of no missing values, when other wouldn't be needed? Could the same dtype be returned then? This is my case, since I'm re-purposing where to do sel for non-dimension coordinates.

Could you give a concrete example of what this would look like?

It seems rather unlikely to me to have an example of where with drop=True where the condition is exactly aligned with the grid, such that there are no missing values.

I guess it could happen if you're trying to index out exactly one element along a dimension?

In the long term, the cleaner solution for this will be some form for support for more flexibly / multi-dimensional indexing.

What about the case of no missing values, when other wouldn't be needed? Could the same dtype be returned then? This is my case, since I'm re-purposing where to do sel for non-dimension coordinates.

I'm capable of just recasting for my use case, if this is becoming an idea that would be difficult to maintain/document.

The trouble with returning the same dtype for uint16 values is that there's no easy way to have a missing value for uint16.

I don't entirely remember why we don't allow other in where if drop=True, but indeed that seems like a clean solution.

I suspect it might have something to do with alignment. But as long as other is already aligned with the result of aligning self and other (e.g., if other is a scalar, which is probably typical), then it should be fine allow for the other argument.

If drop=True, would it be problematic to return the same dtype or allow other?

My use case is a simple slicing of a dataset -- no missing values. The use of where is due to one of selections being on a non-dimension coordinate (#2028).

I can workaround using astype, but will say I was mildly surprised by this feature. I now understand why it's there. Our code is old and the data is intermediate and never deeply inspected -- I only noticed this when we started using a memory-intensive algorithm and surprised how much space was taken by our supposed uint16 data. :)

Looks great. You did well!

@dcherian Ok, I think I proposed a change correctly - never done this before.

@pmallas it would be nice to update the docstring to make that clear if you are up for it

Yes, I read the return type as the 'same type as caller' and at first I expected the array type to be the same. I soon realized that means a DataArray or DataSet. And for your output array to support nan values, it has to be float. My bad - sorry for the clutter.

@pmallas - it looks like you figured this out but I'll just report on what was likely the confusion here.

Xarray's where methods use np.nan as the default other argument, this causes the type to be cast to a float. If you want to maintain a integer type, you'll need to specify another value for other.

xref: http://xarray.pydata.org/en/stable/computation.html#missing-values, http://xarray.pydata.org/en/stable/generated/xarray.DataArray.where.html