[Numpy-discussion] ufunc oddities

[Robert Kern]

On Sat, May 24, 2008 at 9:09 PM, Charles R Harris
<charlesr.harris at gmail.com> wrote:
>
> On Sat, May 24, 2008 at 7:47 PM, Robert Kern <robert.kern at gmail.com> wrote:
>>
>> On Sat, May 24, 2008 at 8:31 PM, Charles R Harris
>> <charlesr.harris at gmail.com> 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