On Fri, Jul 12, 2013 at 3:35 PM, Frédéric Bastien <[email protected]> wrote: > 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 >
I thought Benjamin sounds pretty convincing, and since I never use this, I don't care. However, I (and I'm pretty convinced all statsmodels code) uses equality comparison only element wise. Getting a boolean back is an indicator for a bug, which is most of the time easy to trace back. There is an inconsistency in the behavior with the inequalities. >>> np.array([1,2,3]) < np.array([1,2]) Traceback (most recent call last): File "<stdin>", line 1, in <module> ValueError: shape mismatch: objects cannot be broadcast to a single shape >>> np.array([1,2,3]) <= np.array([1,2]) Traceback (most recent call last): File "<stdin>", line 1, in <module> ValueError: shape mismatch: objects cannot be broadcast to a single shape >>> (np.array([1,2,3]) == np.array([1,2])).any() Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'bool' object has no attribute 'any' The last one could be misleading and difficult to catch. >>> np.any(np.array([1,2,3]) == np.array([1,2])) False numpy 1.5.1 since I'm playing rear guard Josef Josef _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
