[Numpy-discussion] TypeError in dtype.__eq__()

[Robert Kern]

On Sun, Jan 11, 2009 at 15:13, Bryan Cole <bryan at cole.uklinux.net> wrote:
>
>> > However, also note
>> > that with ndarray's rich comparisons, such membership testing will
>> > fail with ndarrays, too.
>>
>> This poses a similarly big problem. I can't understand this behaviour
>> either:
>
> OK, I can now. After equality testing each item, the result must be cast
> to bool. This is where the truth-testing comes in.
>
> Testing array membership in lists does work, just so long as there are
> no numerical objects in the list. Any/only equality comparisons which
> return another (bool) ndarray will cause the exception. Thus, the error
> is not triggered in PyYAML.
>
> FWIW, I don't like the policy of forbidding truth testing on bare
> arrays. I'd prefer that ndarray.__nonzero__() implicitly call
> ndarray.all(). For my use-cases, this is what I want >90% of the time.
> Where any() is required, this must be made explicit. However, I
> understand the logic behind raising an exception and presumably others
> prefer this.

That almost works for == but doesn't for !=. We used to use .any() in
Numeric (if any element is nonzero, then the array is nonzero). Many
people were confused. There was a lot of broken code out there. Moving
to numpy, we decided to prevent that kind of silently broken code.

In any case, it still wouldn't work. Because the argument are
broadcasted against each other, you can have two differently shaped
arrays compare equal. E.g. (ones([5,3]) == 1.0).all() == True.

> Ultimately, I'm forced to conclude that the idea that membership testing
> should always succeed was bogus. Bummer.

Yup. Sorry. It's an unfortunate effect of allowing rich comparisons.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco