Howdy all,
We've got these spiffy comparisons now (thanks Travis et al.!):
] >>> 2 <= arange(8) ] array([0, 0, 1, 1, 1, 1, 1, 1])
but, as noted in the rich comparison PEP, they don't chain:
] >>> 2 <= arange(8) < 6 ] array([1, 1, 1, 1, 1, 1, 0, 0])
since
x <= y < z
is equivalent to
x <= y and y < z
and we don't get to overload "and" :-(. But we did overload "&" long ago, and bitwise_and is equivalent to logical_and if the arguments are only 1 or 0, which is what our comparisons return (I think?). So
(x <= y) & (y < z)
seems like it might be a semi-reasonable substitute, and is shorter and appeals more to my preferring-operators-over-functions eyes, than
Numeric.logical_and(x <= y, y < z)
(which still beats the ^%$#&^(*&*^ out of
Numeric.logical_and(Numeric.less_equal(x, y), Numeric.less(y, z))
). But I'm a bit squeamish about it. Cons that I see are:
- Do our comparisons really and truly ALWAYS return 1 or 0, even with Infs and Nans and whatnot?
- It's potentially misleading for readers of the code.
- It just seems kinda wrong, even if it does look better.
So, what think you?
bitwise, bytefoolish-ly y'rs, Warren Focke
Warren Focke wrote:
] >>> 2 <= arange(8) ] array([0, 0, 1, 1, 1, 1, 1, 1])
but, as noted in the rich comparison PEP, they don't chain:
x <= y and y < z
and we don't get to overload "and" :-(.
Clearly that would be nice. Why wasn't "and" allowed to be overloaded when the rest of rich comparisons was allowed?
(x <= y) & (y < z)
seems like it might be a semi-reasonable substitute, and is shorter and appeals more to my preferring-operators-over-functions eyes, than
Numeric.logical_and(x <= y, y < z)
It looks fine to me as well.
- Do our comparisons really and truly ALWAYS return 1 or 0, even with Infs
and Nans and whatnot?
Good question. There was a lot of discussion here recently about what level of support NumPy should give to NaNs an Inf. Personally, I'd like to see a well integrated support for it, which would include comparisons (though bitwise could still be a problem). Of course, I have neither the time nor the knowledge to do it, so I'll just have to wait...
There has also been talk of a "logical" array type. Is that going to happen? If so, it would be the obvious choice to be returned from a comparison and we could make sure the bitwise & and | work with it. I notice that currently (I'm running 2.0, so ignore me if this has changed) comparisons return an array of python Integers which seems a massive waste of space.
- It's potentially misleading for readers of the code.
well, yes, unless we really do have a 1 bit logical array type.
-Chris
participants (2)
-
Chris Barker -
Warren Focke