You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
xr.Dataset.where and xr.DataArray.where currently do not allow providing both other and drop=True, stating that they are mutually exclusive. Conceptually, this doesn't strike me as true. Drop does not drop all points where cond is False, only those where an entire coordinate label evaluates to False. This is most important when trying to avoid type promotion, such as in the below example, where an integer FillValue might be preferred over dtypes.NA.
However, the combination of other and drop=True is not allowed:
In [5]: da.where(da>6, -1, drop=True)
---------------------------------------------------------------------------ValueErrorTraceback (mostrecentcalllast)
InputIn [5], in<module>---->1da.where(da>6, -1, drop=True)
File~/miniconda3/envs/rhodium-env/lib/python3.10/site-packages/xarray/core/common.py:1268, inDataWithCoords.where(self, cond, other, drop)
1266ifdrop:
1267ifotherisnotdtypes.NA:
->1268raiseValueError("cannot set `other` if drop=True")
1270ifnotisinstance(cond, (Dataset, DataArray)):
1271raiseTypeError(
1272f"cond argument is {cond!r} but must be a {Dataset!r} or {DataArray!r}"1273 )
ValueError: cannotset`other`ifdrop=True
This could easily be reworked to check for valid handling of both arguments.
Describe alternatives you've considered
No response
Additional context
I haven't yet investigated what would happen with chunked, sparse, or other complex arrays, or if it's compatible with trees and other things on the roadmap. It's possible this breaks things I'm not imagining. Currently, where(cond, other) and where(cond, drop=True) are well-tested, flexible operations, and I don't see why allowing their union would break anything, but I'll wait to hear from the experts on that front!
I'm definitely open to creating a pull request (and have the simple implementation I've outlined here ready to go).
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem?
xr.Dataset.where
andxr.DataArray.where
currently do not allow providing bothother
anddrop=True
, stating that they are mutually exclusive. Conceptually, this doesn't strike me as true. Drop does not drop all points wherecond
is False, only those where an entire coordinate label evaluates to False. This is most important when trying to avoid type promotion, such as in the below example, where an integer FillValue might be preferred overdtypes.NA
.If
other
is not provided, the array is promoted tofloat64
to accommodate the default,dtypes.NA
:However, the combination of
other
anddrop=True
is not allowed:Describe the solution you'd like
Current implementation
The current behavior is enforced within the block handling the
drop
argument (currently https://github.com/pydata/xarray/blob/main/xarray/core/common.py#L1266-L1268):Proposed fix
I just removed the above if statement on a fork, and the example now works!
Making this change fails a single test in https://github.com/pydata/xarray/blob/main/xarray/tests/test_dataset.py#L4548-L4549, which explicitly checks for this behavior:
This could easily be reworked to check for valid handling of both arguments.
Describe alternatives you've considered
No response
Additional context
I haven't yet investigated what would happen with chunked, sparse, or other complex arrays, or if it's compatible with trees and other things on the roadmap. It's possible this breaks things I'm not imagining. Currently,
where(cond, other)
andwhere(cond, drop=True)
are well-tested, flexible operations, and I don't see why allowing their union would break anything, but I'll wait to hear from the experts on that front!I'm definitely open to creating a pull request (and have the simple implementation I've outlined here ready to go).
The text was updated successfully, but these errors were encountered: