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

Sebastian Berg sebastian at sipsolutions.net
Mon Jul 15 12:18:44 EDT 2013


On Mon, 2013-07-15 at 17:12 +0200, bruno Piguet wrote:
> 
> 
> 
> 2013/7/15 Frédéric Bastien <nouiz at nouiz.org>
>         Just a question, should == behave like a ufunc or like python
>         == for tuple?
>         
> 
> 
> That's what I was also wondering.

I am not sure I understand the question. Of course == should be
(mostly?) identical to np.equal. Things like
arr[arr == 0] = -1
etc., etc., are a common design pattern. Operations on arrays are
element-wise by default, "falling back" to the python tuple/container
behaviour" is a special case and I do not see a good reason for it,
except possibly backward compatibility.

Personally I doubt anyone who seriously uses numpy, uses the
np.array([1, 2, 3]) == np.array([1,2]) -> False
behaviour, and it seems a bit like a trap to me, because suddenly you
get:
np.array([1, 2, 3]) == np.array([1]) -> np.array([True, False, False])

(Though in combination with np.all, it can make sense and is then
identical to np.array_equiv/np.array_equal)

- Sebastian

> I see the advantage of consistency for newcomers.
> I'm not experienced enough to see if this is a problem for numerical
> practitionners Maybe they wouldn't even imagine that "==" applied to
> arrays could do anything else than element-wise comparison ? 
> 
> "Explicit is better than implicit" : to me,  np.equal(x, y) is more
> explicit than "x == y".
> 
> But "Beautiful is better than ugly". Is np.equal(x, y) ugly ? 
> 
> 
> Bruno.
> 
> 
> 
>  
> 
>         I think that all ndarray comparision (==, !=, <=, ...) should
>         behave the same. If they don't (like it was said), making them
>         consistent is good. What is the minimal change to have them
>         behave the same? From my understanding, it is your proposal to
>         change == and != to behave like real ufunc. But I'm not sure
>         if the minimal change is the best, for new user, what they
>         will expect more? The ufunc of the python behavior?
>         
>         
>         Anyway, I see the advantage to simplify the interface to
>         something more consistent.
>         
>         
>         Anyway, if we make all comparison behave like ufunc, there is
>         array_equal as said to have the python behavior of ==, is it
>         useful to have equivalent function the other comparison? Do
>         they already exist.
>         
>         
>         thanks
>         
>         
>         
>         Fred
>         
>         
>         On Mon, Jul 15, 2013 at 10:20 AM, Nathaniel Smith
>         <njs at pobox.com> wrote:
>                 On Mon, Jul 15, 2013 at 2:09 PM, bruno Piguet
>                 <bruno.piguet at gmail.com> 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 ?
>                 
>                 
>                 The numpy equivalent to Python's scalar "==" is called
>                 array_equal,
>                 and that does indeed behave the same:
>                 
>                 In [5]: np.array_equal([3, 4], [2, 3, 4])
>                 Out[5]: False
>                 
>                 But in numpy, the name "==" is shorthand for the ufunc
>                 np.equal, which
>                 raises an error:
>                 
>                 In [8]: np.equal([3, 4], [2, 3, 4])
>                 ValueError: operands could not be broadcast together
>                 with shapes (2) (3)
>                 
>                 -n
>                 _______________________________________________
>                 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