On Sat, May 24, 2008 at 9:09 PM, Charles R Harris <[EMAIL PROTECTED]> wrote: > > On Sat, May 24, 2008 at 7:47 PM, Robert Kern <[EMAIL PROTECTED]> wrote: >> >> On Sat, May 24, 2008 at 8:31 PM, Charles R Harris >> <[EMAIL PROTECTED]> wrote: >> > Hi All, >> > >> > I'm writing tests for ufuncs and turned up some oddities: >> > >> > In [4]: degrees(True) >> > Out[4]: 57.29578 >> > >> > In [5]: radians(True) >> > Out[5]: 0.017453292 >> > >> > In [6]: sin(True) >> > Out[6]: 0.84147096 >> > >> > Do we want numeric functions to apply to booleans? >> >> I don't see a good reason to prevent it. They are just 0 and 1 under >> the covers and behave like it everywhere else (e.g. True + True == 2 >> and the very useful boolean_mask.sum()). > > True + True == 1
No, True + True == 2. Try it. We might have made boolean arrays behave differently than Python bool objects, but that's not what I wrote. > In [5]: x + x > Out[5]: array([ True, True], dtype=bool) > > In [6]: (x + x).astype(int) > Out[6]: array([1, 1]) > > That is how the inner loop is implemented. Fine. Internally, boolean arrays operated with boolean arrays with a boolean output work slightly differently than Python bool objects (which always act like integers). However, ufuncs like sin(), floor_divide(), etc. convert the argument to a dtype they can accept so True -> 1.0 or True -> uint8(1) and the ufunc goes on it's merry way. That's fine. Leave it alone. I don't think it's a problem, much less one worth trying to solve. -- 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 _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
