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 :-(. -n _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
