[Numpy-discussion] ufunc oddities
Sat May 24 21:25:34 CDT 2008
On Sat, May 24, 2008 at 9:09 PM, Charles R Harris
> On Sat, May 24, 2008 at 7:47 PM, Robert Kern <email@example.com> wrote:
>> On Sat, May 24, 2008 at 8:31 PM, Charles R Harris
>> <firstname.lastname@example.org> wrote:
>> > Hi All,
>> > I'm writing tests for ufuncs and turned up some oddities:
>> > In : degrees(True)
>> > Out: 57.29578
>> > In : radians(True)
>> > Out: 0.017453292
>> > In : sin(True)
>> > Out: 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 : x + x
> Out: array([ True, True], dtype=bool)
> In : (x + x).astype(int)
> Out: 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.
"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
More information about the Numpy-discussion