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:
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?
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 -- Christopher Barker, Ph.D. ChrisHBarker@home.net --- --- --- http://members.home.net/barkerlohmann ---@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Oil Spill Modeling ------ @ ------ @ ------ @ Water Resources Engineering ------- --------- -------- Coastal and Fluvial Hydrodynamics -------------------------------------- ------------------------------------------------------------------------
Warren Focke wrote:
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?
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 -- Christopher Barker, Ph.D. ChrisHBarker@home.net --- --- --- http://members.home.net/barkerlohmann ---@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Oil Spill Modeling ------ @ ------ @ ------ @ Water Resources Engineering ------- --------- -------- Coastal and Fluvial Hydrodynamics -------------------------------------- ------------------------------------------------------------------------
participants (2)
-
Chris Barker -
Warren Focke