MAINT: Revert boolean casting back to elementwise comparisons in trim_zeros
#17058
Conversation
|
|
||
| if arr.ndim != 1: | ||
| arr_any = np.asanyarray(filt) | ||
| arr = arr_any != 0 if arr_any.dtype != bool else arr_any |
There was a problem hiding this comment.
Prevents converting a bool array into another identical bool array.
| arr_any = np.asanyarray(filt) | ||
| arr = arr_any != 0 if arr_any.dtype != bool else arr_any | ||
|
|
||
| if arr is False: |
There was a problem hiding this comment.
Certain data types do not support elementwise comparisons with 0.
Note that the intersection between aforementioned dtypes and those who cannot be cast into boolean arrays is pretty large. In this sense little changes with respect to the previous pull request: str, bytes & structured arrays still aren't supported.
|
Looks good to me, but probably best for the original reviewers to make the call. |
|
I'm not sure if should make this change, as it makes the definition of zero in # TODO: this works around .astype(bool) not working properly (gh-9847)
if np.issubdtype(a.dtype, np.character):
a_bool = a != a.dtype.type()
else:
a_bool = a.astype(np.bool_, copy=False)This manifests as actually differences for object arrays with elements where I'm pretty sure an |
| @@ -1631,7 +1631,7 @@ def trim_zeros(filt, trim='fb'): | |||
| # Numpy 1.20.0, 2020-07-31 | |||
| warning = DeprecationWarning( | |||
| "in the future trim_zeros will require a 1-D array as input " | |||
| "that is compatible with ndarray.astype(bool)" | |||
| "that supports elementwise comparisons with zero" | |||
There was a problem hiding this comment.
We should move this deprecation to after the old implementation. Lets not worry too much about a possible changed exception type (although if you like that would be fine. But None == 0 always failed, and should fail roughly identically. So we not should give a DeprecationWarning, when a correct error is given!
I do think we should add at least one tests for the == 0 behaviour, and compare it to the old behaviour.
There was a problem hiding this comment.
The warning has been moved as of f977f57.
Can you clarify a bit more about the None == 0? Are you talking about filt=None or filt=[None, ...] here?
The former case would always raise an exception (and still does) while the latter would pass through trim_zeros() without any trimming (as None != 0).
If we go ahead with this pull request then the behavior of the latter will also remain unchanged (though a warning will be issues due to the creation of an object array without explicitly specifying the object dtype).
There was a problem hiding this comment.
Yes, I was talking about the behaviour of the latter. It creates an object array now, I do not think it gives a warning? But even if it does, I would be happy with that.
There was a problem hiding this comment.
It creates an object array now, I do not think it gives a warning?
You're right, I was confused with the deprecation of ragged arrays.
I think the current behavior of not issuing a warning should be fine,
as object arrays will pass through trim_zero() just as they always have:
leading / trailing elements will be trimmed if they are equivalent to 0 and they'll be ignored otherwise.
In any case, I just added a few tests related to object arrays in 26734ef.
trim_zerostrim_zeros
|
Thanks @BvB93 |
Followup on #16911:
Replaces the boolean casting added in aforementioned pull request with an (elementwise) comparison to
0.This his two main consequences:
trim_zeros(). Note that the performance gains seem to vary on a system by system basis (ENH: Speed up trim_zeros #16911 (comment), ENH: Speed up trim_zeros #16911 (comment) & ENH: Speed up trim_zeros #16911 (comment)).ndarraysubclasses which do not support direct boolean casting such asastropy.Quantity(Test failure with Numpy dev astropy/astropy#10638 & ENH: Speed up trim_zeros #16911 (comment)). Note that the original spirit of the function is retained: finding and trimming leading/trailing0s.