From: Warren F. <focke@SLAC.Stanford.EDU> - 2001-05-18 22:35:28
|
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 |