On Mon, 2013-07-15 at 17:12 +0200, bruno Piguet wrote: > > > > 2013/7/15 Frédéric Bastien <[email protected]> > 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 > <[email protected]> wrote: > On Mon, Jul 15, 2013 at 2:09 PM, bruno Piguet > <[email protected]> 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 > [email protected] > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > > > > _______________________________________________ > NumPy-Discussion mailing list > [email protected] > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > > > _______________________________________________ > NumPy-Discussion mailing list > [email protected] > http://mail.scipy.org/mailman/listinfo/numpy-discussion _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
