-
-
Notifications
You must be signed in to change notification settings - Fork 10.9k
BUG: __array_priority__ > 0 in float subclass causes comparison with np.float64 to fail #6133
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
Seems like this could be related to #4766. |
Some more information: x = np.float64(1)
c = make_class(1)
np.generic.__lt__(x, c(2))
>>> False
import numpy.core.umath as umath
umath.less(x, c(2))
>>> True |
This error is also present with 2.7.6 (64 bit) and numpy 1.9.1 |
I tracked this down a bit. The problem here is that in numpy 1.9.3, numpy converts This can be solved by changing this to numpy 1.8.2 does not convert the input to an array before calling the
|
Closing, the code at the beginning of the issue now returns True. Not clear when the behaviour changed. Please reopen if there is more to do here. |
Uh oh!
There was an error while loading. Please reload this page.
Consider a subclass of
float
:Now we try to compare an instance of
Bar
with a numpy float64:Puzzled, we try the following
Running
test
over a few choice values we find (note that the__array_priority__
ofnp.float64
is-1000000.0
)As you can see, if
__array_priority__
is greater than0
, the comparison fails.Whether our custom
__array_priority__
is greater or less thannp.float64
's__array_priority__
doesn't matter.Some of my colleagues tried this on their machines and we found that this problem only happens with python
2.7.6
(64 bit) and numpy1.9.2
. Using either that python version or that numpy version alone does not reproduce the bug. It only happens when both of those versions are used together.Here is a table of python and numpy versions and whether or not this bug shows up
Also posted to Stackoverflow.
Summary 2019-05-03 by @seberg
This issue still seems present in the 1.16.x branch (python 2). Since it is python 2 only, we can probably close it at some point. Although, I did not follow whether there is some additional underlying problem.
The text was updated successfully, but these errors were encountered: