Repository navigation
BUG: Operator equal supports void and np.equal does not #9147
Description
>>> x = np.array([(0, 1, 0)] * 10, dtype=[('f0', '<i4'), ('f1', '<i4'), ('f2', '<i4')])
>>> x == x
array([ True, True, True, True, True, True, True, True, True, True], dtype=bool)
>>> np.equal(x, x)
FutureWarning: elementwise comparison failed; returning scalar instead, but in the future will perform elementwise comparison
NotImplementedPresumably this has ramifications for users overloading __array_ufunc__ with @shoyer's mixin class, causing operations to fail on structured dtypes - as these do not pass through ndarray.__eq__, which seems to special case things to make them work
Activity
shoyer commentedon May 20, 2017
I think this is an unintended and/or unforeseen consequence of a partial fix for issues with
==in old versions of numpy (see #5964).As you can see, this deprecation notice went in about two years ago now (NumPy 1.10). Can we finally fix the broken behavior? It seems like we've given more than enough warning to anyone who may have been relying on the old broken behavior.
charris commentedon May 20, 2017
@shoyer The 1.10 deprecations/futurwarnings will expire in 1.14. There are several that I will be putting in a PR soonish to change.
seberg commentedon May 21, 2017
ufuncs currently don't support flexible types, so string and voids are specifically handled by
__eq__and not send tonp.equal.mhvk commentedon May 21, 2017
The special handling gets the elements and compares them in turn -- and those comparisons do get send to any
__array_ufunc__, as does the combination of them vialogical_and, so from that perspective it is OK at least forndarraysubclasses.For array-likes it is perhaps not unreasonable for the mixin to not try to also support structured array-likes in a similar way. Though it would be good to document this.
mhvk commentedon May 21, 2017
Looking in more detail at the source for
array_richcompareatPy_EQ( https://github.com/numpy/numpy/blob/master/numpy/core/src/multiarray/arrayobject.c#L1302), I see that theRICHCMP_GIVE_UP_IF_NEEDEDcomes after the check forvoid, rather than before, which seems wrong. See new issue #9153.Similarly, the check for string comes even before any of this, which may also not be quite right. Looking in detail, it falls through if
otheris not also a string-like array, so this case works for array-likes. And for subclasses, since theufuncdoesn't work for strings, I guess one has little choice but to do what is done there; subclasses can override simply by defining__eq__and their__eq__will get called.ahaldane commentedon Dec 5, 2018
Just want to say that I just hit this bug while trying to implement
np.equalin__array_ufunc__for my Masked-ducktype. More in detail, my ducktype inherits fromnumpy.lib.mixins.NDArrayOperatorsMixinwhich implements__eq__ = _binary_method(um.equal, 'eq'). In other words it assumes__eq__can be replaced bynp.equal, however this bug means that is not true for structured arrays.So anybody who uses
NDArrayOperatorsMixinprobably can't handle structured arrays currently.mhvk commentedon Dec 6, 2018
Yes, structured arrays are a bit of a step-child currently, with the difficulty of defining ufuncs for them
[-]BUG: Operator equals works where np.equal does not[/-][+]BUG: Operator equal supports `void` and np.equal does not[/+]seberg commentedon Dec 7, 2022
Changed the title, strings are in the ufunc now. Void could be moved, although it is a bit of a smaller project to do so.
A new difference is that
==will return an array of allFalsewhen dtypes cannot be compared whilenp.equal()errors.mattip commentedon Jul 22, 2026
Closing this as stale.