On Sat, Jul 13, 2013 at 9:14 AM, Nathaniel Smith <[email protected]> wrote: > On Fri, Jul 12, 2013 at 2:13 PM, 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. > > But it does break semantics. Sure, it tells you that the arrays aren't > equal -- but that's not the question you asked. "==" is not "are these > arrays equal"; it's "is each pair of broadcasted aligned elements in > these arrays equal", and these are totally different operations. It's > unfortunate that "==" is a somewhat confusing name, but that's no > reason to mix things up like this. "+" in python sometimes means "add > all elements" and sometimes means "concatenate", but no-one would > argue that ndarray.__add__ should the former when the arrays were > broadcastable and the latter when they weren't. This is the same > thing. > > "Errors should never pass silently", "In the face of ambiguity, refuse > the temptation to guess." > > There's really no sensible interface here -- notice that '==' can > return False but can never return True, and Josef gave an example of > where it can silently produce misleading results. So to me it seems > like a clear bug, but one of the sort that has a higher probability > than usual that someone somewhere is depending on it... which makes it > less clear what exactly to do with it. > > I guess one option is to just start raising errors in the first RC and > see whether anyone complains! But people people don't seem to test the > RCs enough to make this entirely reliable :-(.
I'm now +1 on the exception that Sebastian proposed. I like consistency, and having a more straightforward mental model of the numpy behavior for elementwise operations, that don't pretend sometimes to be "python" (when I'm doing array math), like this >>> [1,2,3] < [1,2] False >>> [1,2,3] > [1,2] True Josef > > -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
