[Numpy-discussion] Allow == and != to raise errors

bruno Piguet bruno.piguet at gmail.com
Mon Jul 15 09:09:12 EDT 2013


Python itself doesn't raise an exception in such cases :

>>> (3,4) != (2, 3, 4)
True
>>> (3,4) == (2, 3, 4)
False


Should numpy behave differently ?

Bruno.


2013/7/12 Frédéric Bastien <nouiz at nouiz.org>

> I also don't like that idea, but I'm not able to come to a good reasoning
> like Benjamin.
>
> I don't see advantage to this change and the reason isn't good enough to
> justify breaking the interface I think.
>
> But I don't think we rely on this, so if the change goes in, it probably
> won't break stuff or they will be easily seen and repared.
>
> Fred
>
>
> On Fri, Jul 12, 2013 at 9:13 AM, Benjamin Root <ben.root at ou.edu> wrote:
>
>> I can see where you are getting at, but I would have to disagree.  First
>> of all, when a comparison between two mis-shaped arrays occur, you get back
>> a bone fide python boolean, not a numpy array of bools. So if any action
>> was taken on the result of such a comparison assumed that the result was
>> some sort of an array, it would fail (yes, this does make it a bit
>> difficult to trace back the source of the problem, but not impossible).
>>
>> Second, no semantics are broken with this. Are the arrays equal or not?
>> If they weren't broadcastible, then returning False for == and True for !=
>> makes perfect sense to me. At least, that is my take on it.
>>
>> Cheers!
>> Ben Root
>>
>>
>>
>> On Fri, Jul 12, 2013 at 8:38 AM, Sebastian Berg <
>> sebastian at sipsolutions.net> wrote:
>>
>>> Hey,
>>>
>>> the array comparisons == and != never raise errors but instead simply
>>> return False for invalid comparisons.
>>>
>>> The main example are arrays of non-matching dimensions, and object
>>> arrays with invalid element-wise comparisons:
>>>
>>> In [1]: np.array([1,2,3]) == np.array([1,2])
>>> Out[1]: False
>>>
>>> In [2]: np.array([1, np.array([2, 3])], dtype=object) == [1, 2]
>>> Out[2]: False
>>>
>>> This seems wrong to me, and I am sure not just me. I doubt any large
>>> projects makes use of such comparisons and assume that most would prefer
>>> the shape mismatch to raise an error, so I would like to change it. But
>>> I am a bit unsure especially about smaller projects. So to keep the
>>> transition a bit safer could imagine implementing a FutureWarning for
>>> these cases (and that would at least notify new users that what they are
>>> doing doesn't seem like the right thing).
>>>
>>> So the question is: Is such a change safe enough, or is there some good
>>> reason for the current behavior that I am missing?
>>>
>>> Regards,
>>>
>>> Sebastian
>>>
>>> (There may be other issues with structured types that would continue
>>> returning False I think, because neither side knows how to compare)
>>>
>>> _______________________________________________
>>> NumPy-Discussion mailing list
>>> NumPy-Discussion at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>>
>>
>>
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion at scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20130715/6c758210/attachment.html>


More information about the NumPy-Discussion mailing list