6 ms·

Here's a better resource for understanding how conains works which actually looks at the source/documentation instead of trying to understand it intuitively

Here's a better resource for understanding how __conains__ works which actually looks at the source/documentation instead of trying to understand it intuitively: https://stackoverflow.com/questions/18320624/how-does-contains-work-for-ndarrays https://stackoverflow.com/questions/18320624/how-does-contai... Answer: `a in b` is the same as `(a == b).any()`. This really only makes sense when `a` is a scalar and any behavior for other types of arrays are more "accidental" than designed.

Someone 4y ago
Even that took me a while to understand it and, I guess, is another example of Numpy’s absurdity. My initial thought was “None of the examples have arguments that are equal to each other, so that should evaluate to false.any()”, but that would mean all should return the same value, so that can’t be true, so I figured out that Numpy overloads/changes a == b to do item-by-item comparison on arrays, and return an array of booleans. But then, the statement “This really only makes sense when `a` is a scalar” doesn’t make sense to me. That seems to indicate Numpy also overloads a == b as a comparison of each element of a with a single value b and vice versa, but that doesn’t make sense, given that arrays can contain arrays, making it impossible to discriminate between [1,2] as a two-item sequence and [1,2] as a single-item sequence where the item is a two-item sequence. Reading https://stackoverflow.com/questions/10580676/comparing-two-numpy-arrays-for-equality-element-wise https://stackoverflow.com/questions/10580676/comparing-two-n... further strengthens my impression that one should avoid using == in Numpy.
gnulinux 4y ago
Well yeah you're right OP could have explained this better; but this argues their point. From the definition that `a in b` is `(a == b).any()` it's trivial to see things like `np.array([1, 0, 0]) in np.array([1, 2, 3])` will return `True` too, which is absurd, as the title says. I find it hard to believe when numpy team was designing the API they missed this.
- kzrdude 4y ago
  It's trivial to see some things and other things use broadcasting and that's not quite trivial :)
  - gnulinux 4y ago
    My point is that even the trivial implications of the definition are absurd; without inspecting non-trivial broadcasting cases we can already determine the API is poorly designed.
cuteboy19 4y ago
Does == ignore dtype?
- rich_sasha 4y ago
  Yes. 1 == 1.0

Here's a better resource for understanding how __conains__ works which actually looks at the source/documentation instead of trying to understand it intuitively

Someone 4y ago

Even that took me a while to understand it and, I guess, is another example of Numpy’s absurdity. My initial thought was “None of the examples have arguments that are equal to each other, so that should evaluate to false.any()”, but that would mean all should return the same value, so that can’t be true, so I figured out that Numpy overloads/changes a == b to do item-by-item comparison on arrays, and return an array of booleans. But then, the statement “This really only makes sense when `a` is a scalar” doesn’t make sense to me. That seems to indicate Numpy also overloads a == b as a comparison of each element of a with a single value b and vice versa, but that doesn’t make sense, given that arrays can contain arrays, making it impossible to discriminate between [1,2] as a two-item sequence and [1,2] as a single-item sequence where the item is a two-item sequence. Reading https://stackoverflow.com/questions/10580676/comparing-two-numpy-arrays-for-equality-element-wise https://stackoverflow.com/questions/10580676/comparing-two-n... further strengthens my impression that one should avoid using == in Numpy.

gnulinux 4y ago

Well yeah you're right OP could have explained this better; but this argues their point. From the definition that `a in b` is `(a == b).any()` it's trivial to see things like `np.array([1, 0, 0]) in np.array([1, 2, 3])` will return `True` too, which is absurd, as the title says. I find it hard to believe when numpy team was designing the API they missed this.

kzrdude 4y ago
It's trivial to see some things and other things use broadcasting and that's not quite trivial :)
- gnulinux 4y ago
  My point is that even the trivial implications of the definition are absurd; without inspecting non-trivial broadcasting cases we can already determine the API is poorly designed.

cuteboy19 4y ago

Does == ignore dtype?

rich_sasha 4y ago
Yes. 1 == 1.0