[Numpy-discussion] Allow == and != to raise errors

[josef.pktd at gmail.com]

On Sat, Jul 13, 2013 at 9:14 AM, Nathaniel Smith <njs at pobox.com> wrote:
> On Fri, Jul 12, 2013 at 2:13 PM, Benjamin Root <ben.root at ou.edu> 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
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion