Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork10.9k
BUG: Silencing errors of filled_value's casting in array_finalize in MaskedArray#27596
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:main
Are you sure you want to change the base?
Uh oh!
There was an error while loading.Please reload this page.
Conversation
@fengluoqiuwu two things here:
|
The
I will add it later. |
Thanks! Looking a bit closer, I suspect this is right and we could probably just do it. We don't know that the dtype matches, and we have to just fall back to the default when the "inherited" fill-value fails (this is part of The reason I ask about where it comes from is that it may better to handle this in In this case, I actually like if we could audit/clean up things a bit more. That probably means pushing this logic into I think in most places probably we should fall back to (It is unfortunate, that this was always weird, but the integer casting is now floating up these issues...) |
I think using the default value is better. In the comment for |
This is the most minimal fix I could think off... If we have uintsstill use the out-of-bounds value, but make it uint. This is becausethe code uses copyto with the default same-kind casting in places...This doesn't remove all the other quirks, and surely, it is a behaviorchange in some awkward situations (since you got a uint, someone mightmix 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 longertime.A more thorough fix may be to just always store the exact dtype, butit would propagate differently e.g. when casting. A start for thisis currently innumpygh-27596.Closesnumpygh-27269,numpygh-27580
This is the most minimal fix I could think off... If we have uintsstill use the out-of-bounds value, but make it uint. This is becausethe code uses copyto with the default same-kind casting in places...This doesn't remove all the other quirks, and surely, it is a behaviorchange in some awkward situations (since you got a uint, someone mightmix 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 longertime.A more thorough fix may be to just always store the exact dtype, butit would propagate differently e.g. when casting. A start for thisis currently innumpygh-27596.Closesnumpygh-27269,numpygh-27580
This is the most minimal fix I could think off... If we have uintsstill use the out-of-bounds value, but make it uint. This is becausethe code uses copyto with the default same-kind casting in places...This doesn't remove all the other quirks, and surely, it is a behaviorchange in some awkward situations (since you got a uint, someone mightmix 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 longertime.A more thorough fix may be to just always store the exact dtype, butit would propagate differently e.g. when casting. A start for thisis currently innumpygh-27596.Closesnumpygh-27269,numpygh-27580
Uh oh!
There was an error while loading.Please reload this page.
Silencing errors related to the casting of
fill_value
in__array_finalize__
ofMaskedArray
, and using a default value if the originalfill_value
cannot be cast even with the method_check_fill_value
.While this approach may introduce some level of risk, it is reasonable to assume that if users set the
fill_value
themselves, they are aware that it may lead to undefined behavior with specific type casting. It is unfortunate that the casting ofmasked_array
types is hindered simply because we assignedfill_value
with the default value indirectly. This not only causes issues with methods that usedtype=
directly, but also impedes any calls toufunc
that return a dtype different from the original dtype (since calls to theufunc
won't be applied to the storedfill_value
), exacerbating the situation.I believe this is the most effective way to address these issues, rather than designing a new ufunc for
masked_array
or marking whether the value was set by the user or not.fixes#27165