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

Sebastian Berg sebastian at sipsolutions.net
Mon Jul 15 10:21:35 EDT 2013


On Mon, 2013-07-15 at 15:09 +0200, bruno Piguet wrote:
> 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 ?
> 
Yes, because Python tests whether the tuple is different, not whether
the elements are:

>>> (3, 4) == (3, 4)
True
>>> np.array([3, 4]) == np.array([3, 4])
array([ True,  True], dtype=bool)

So doing the test "like python" *changes* the behaviour.

- Sebastian
> 
> 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
>         
> 
> 
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion





More information about the NumPy-Discussion mailing list