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 <[email protected]> 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 < > [email protected]> 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 >> [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
