<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2013/7/15 Frédéric Bastien <span dir="ltr"><<a href="mailto:nouiz@nouiz.org" target="_blank">nouiz@nouiz.org</a>></span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">Just a question, should == behave like a ufunc or like python == for tuple?<div></div></div></blockquote><div><br></div><div>That's what I was also wondering.<br><br></div><div>I see the advantage of consistency for newcomers.<br>
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 ? <br>
<br>"Explicit is better than implicit" : to me,  np.equal(x, y) is more explicit than "x == y".<br></div><div>But "Beautiful is better than ugly". Is np.equal(x, y) ugly ? <br><br></div><div>
Bruno.<br></div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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?<div>


<br></div><div>Anyway, I see the advantage to simplify the interface to something more consistent.</div><div><br></div><div>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.</div>


<div><br></div><div>thanks<br></div><div><br></div><div>Fred</div></div></div><div class=""><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jul 15, 2013 at 10:20 AM, Nathaniel Smith <span dir="ltr"><<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>On Mon, Jul 15, 2013 at 2:09 PM, bruno Piguet <<a href="mailto:bruno.piguet@gmail.com" target="_blank">bruno.piguet@gmail.com</a>> wrote:<br>



> Python itself doesn't raise an exception in such cases :<br>
><br>
>>>> (3,4) != (2, 3, 4)<br>
> True<br>
>>>> (3,4) == (2, 3, 4)<br>
> False<br>
><br>
> Should numpy behave differently ?<br>
<br>
</div>The numpy equivalent to Python's scalar "==" is called array_equal,<br>
and that does indeed behave the same:<br>
<br>
In [5]: np.array_equal([3, 4], [2, 3, 4])<br>
Out[5]: False<br>
<br>
But in numpy, the name "==" is shorthand for the ufunc np.equal, which<br>
raises an error:<br>
<br>
In [8]: np.equal([3, 4], [2, 3, 4])<br>
ValueError: operands could not be broadcast together with shapes (2) (3)<br>
<span><font color="#888888"><br>
-n<br>
</font></span><div><div>_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@scipy.org" target="_blank">NumPy-Discussion@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion" target="_blank">http://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion" target="_blank">http://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
<br></blockquote></div><br></div></div>