-
-
Notifications
You must be signed in to change notification settings - Fork 10.8k
BUG: numpy.ma.min fails for uint dtypes #27580
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Here is another example:
The output of
The masked array The value
Maybe |
np.copyto(result, result.fill_value, where=newmask) In document we can find that fill_value has int64 for integer type, but in the default casting mode , int64 could not be cast to uint8, that is why dtype int8 can run but uint8 failed. Maybe we should add uint64(999999) in default fill_value for usigned integer type or add type check and transform before copyto. |
In result = self.filled(fill_value).min(
axis=axis, out=out, **kwargs).view(type(self))
if result.ndim:
# Set the mask
result.__setmask__(newmask)
# Get rid of Infs
if newmask.ndim:
test = result.fill_value
np.copyto(result, result.fill_value, where=newmask)
elif newmask:
result = masked
return result |
I delete the infinity checking module. |
This is the most minimal fix I could think off... If we have uints still use the out-of-bounds value, but make it uint. This is because the code uses copyto with the default same-kind casting in places... This doesn't remove all the other quirks, and surely, it is a behavior change in some awkward situations (since you got a uint, someone might mix the newly uint value with an integer and get float64 results, etc.) But... it is by far the most minimal fix I could think of after a longer time. A more thorough fix may be to just always store the exact dtype, but it would propagate differently e.g. when casting. A start for this is currently in numpygh-27596. Closes numpygh-27269, numpygh-27580
This is the most minimal fix I could think off... If we have uints still use the out-of-bounds value, but make it uint. This is because the code uses copyto with the default same-kind casting in places... This doesn't remove all the other quirks, and surely, it is a behavior change in some awkward situations (since you got a uint, someone might mix the newly uint value with an integer and get float64 results, etc.) But... it is by far the most minimal fix I could think of after a longer time. A more thorough fix may be to just always store the exact dtype, but it would propagate differently e.g. when casting. A start for this is currently in numpygh-27596. Closes numpygh-27269, numpygh-27580
This is the most minimal fix I could think off... If we have uints still use the out-of-bounds value, but make it uint. This is because the code uses copyto with the default same-kind casting in places... This doesn't remove all the other quirks, and surely, it is a behavior change in some awkward situations (since you got a uint, someone might mix the newly uint value with an integer and get float64 results, etc.) But... it is by far the most minimal fix I could think of after a longer time. A more thorough fix may be to just always store the exact dtype, but it would propagate differently e.g. when casting. A start for this is currently in numpygh-27596. Closes numpygh-27269, numpygh-27580
Describe the issue:
The
numpy.ma.min
operation fails for cases where the input array has adtype = uint
and the resultant array and mask hasndim > 0
. There could be other operations where this same case fails, e.g.,numpy.ma.max
.Reproduce the code example:
Error message:
Python and NumPy Versions:
2.1.2
3.12.5 (main, Oct 14 2024, 12:30:20) [GCC 13.2.0]
Runtime Environment:
No response
Context for the issue:
No response
The text was updated successfully, but these errors were encountered: