
12

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? Chuck
_______________________________________________
Numpydiscussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpydiscussion


On Sat, May 24, 2008 at 7:31 PM, Charles R Harris < [hidden email]> 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?
Some more:
In [15]: x Out[15]: array([ True, False], dtype=bool)
In [16]: floor_divide(x,True) Out[16]: array([1, 0], dtype=int8)
Chuck
_______________________________________________
Numpydiscussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpydiscussion


On Sat, May 24, 2008 at 8:31 PM, Charles R Harris
< [hidden email]> 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()).

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
_______________________________________________
Numpydiscussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpydiscussion


On Sat, May 24, 2008 at 7:47 PM, Robert Kern < [hidden email]> wrote:
On Sat, May 24, 2008 at 8:31 PM, Charles R Harris
< [hidden email]> 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
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.
Chuck
_______________________________________________
Numpydiscussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpydiscussion


On Sat, May 24, 2008 at 9:09 PM, Charles R Harris
< [hidden email]> wrote:
>
> On Sat, May 24, 2008 at 7:47 PM, Robert Kern < [hidden email]> wrote:
>>
>> On Sat, May 24, 2008 at 8:31 PM, Charles R Harris
>> < [hidden email]> 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
_______________________________________________
Numpydiscussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpydiscussion


On Sat, May 24, 2008 at 7:09 PM, Charles R Harris
< [hidden email]> wrote:
>
>
> On Sat, May 24, 2008 at 7:47 PM, Robert Kern < [hidden email]> wrote:
>>
>> On Sat, May 24, 2008 at 8:31 PM, Charles R Harris
>> < [hidden email]> 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
>
> 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.
I think it's interesting how python and numpy bools behave differently.
>> x = np.array([True, True], dtype=bool)
>> x[0] + x[1]
True
>> x[0] & x[1]
True
>>
>> x = [True, True]
>> x[0] + x[1]
2
>> x[0] & x[1]
True
_______________________________________________
Numpydiscussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpydiscussion


On Sat, May 24, 2008 at 9:28 PM, Keith Goodman < [hidden email]> wrote:
> I think it's interesting how python and numpy bools behave differently.
>
>>> x = np.array([True, True], dtype=bool)
>>> x[0] + x[1]
> True
>>> x[0] & x[1]
> True
>>>
>>> x = [True, True]
>>> x[0] + x[1]
> 2
>>> x[0] & x[1]
> True
The difference arises straightforwardly from the principle that numpy
tries not to upcast when you do an operation on two arrays of the same
dtype; True+True==True is of somewhat more use than True+True==False.
Python bools are just ints subclasses to give a nice string
representation.

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
_______________________________________________
Numpydiscussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpydiscussion


On Sat, May 24, 2008 at 8:25 PM, Robert Kern < [hidden email]> wrote:
On Sat, May 24, 2008 at 9:09 PM, Charles R Harris
< [hidden email]> wrote:
>
> On Sat, May 24, 2008 at 7:47 PM, Robert Kern < [hidden email]> wrote:
>>
>> On Sat, May 24, 2008 at 8:31 PM, Charles R Harris
>> < [hidden email]> 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.
Robert, the C code in the inner loop is generated with
/**begin repeat
#TYPE=(BOOL, BYTE,UBYTE,SHORT,USHORT,INT,UINT,LONG,ULONG,LONGLONG,ULONGLONG,FLOAT,DOUBLE,LONGDOUBLE)*2#
#OP=, +*13, ^, *13# #kind=add*14, subtract*14# #typ=(Bool, byte, ubyte, short, ushort, int, uint, long, ulong, longlong, ulonglong, float, double, longdouble)*2# */
Note that  is not the same as +. Also note that subtract is implemented as xor.
Chuck
_______________________________________________
Numpydiscussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpydiscussion


On Sat, May 24, 2008 at 9:37 PM, Charles R Harris
< [hidden email]> wrote:
>
>
> On Sat, May 24, 2008 at 8:25 PM, Robert Kern < [hidden email]> wrote:
>>
>> On Sat, May 24, 2008 at 9:09 PM, Charles R Harris
>> < [hidden email]> wrote:
>> >
>> > On Sat, May 24, 2008 at 7:47 PM, Robert Kern < [hidden email]>
>> > wrote:
>> >>
>> >> On Sat, May 24, 2008 at 8:31 PM, Charles R Harris
>> >> < [hidden email]> 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.
>
> Robert, the C code in the inner loop is generated with
>
> /**begin repeat
>
> #TYPE=(BOOL,
> BYTE,UBYTE,SHORT,USHORT,INT,UINT,LONG,ULONG,LONGLONG,ULONGLONG,FLOAT,DOUBLE,LONGDOUBLE)*2#
> #OP=, +*13, ^, *13#
> #kind=add*14, subtract*14#
> #typ=(Bool, byte, ubyte, short, ushort, int, uint, long, ulong, longlong,
> ulonglong, float, double, longdouble)*2#
> */
>
> Note that  is not the same as +. Also note that subtract is implemented as
> xor.
I'm not sure why you're showing me numpy C code. I am talking about
the Python bools True and False.
$ python
Python 2.5.1 (r251:54869, Apr 18 2007, 22:08:04)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> True + True
2

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
_______________________________________________
Numpydiscussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpydiscussion


On Sat, May 24, 2008 at 8:40 PM, Robert Kern < [hidden email]> wrote:
On Sat, May 24, 2008 at 9:37 PM, Charles R Harris
< [hidden email]> wrote:
>
>
> On Sat, May 24, 2008 at 8:25 PM, Robert Kern < [hidden email]> wrote:
>>
>> On Sat, May 24, 2008 at 9:09 PM, Charles R Harris
>> < [hidden email]> wrote:
>> >
>> > On Sat, May 24, 2008 at 7:47 PM, Robert Kern < [hidden email]>
>> > wrote:
>> >>
>> >> On Sat, May 24, 2008 at 8:31 PM, Charles R Harris
>> >> < [hidden email]> 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.
>
> Robert, the C code in the inner loop is generated with
>
> /**begin repeat
>
> #TYPE=(BOOL,
> BYTE,UBYTE,SHORT,USHORT,INT,UINT,LONG,ULONG,LONGLONG,ULONGLONG,FLOAT,DOUBLE,LONGDOUBLE)*2#
> #OP=, +*13, ^, *13#
> #kind=add*14, subtract*14#
> #typ=(Bool, byte, ubyte, short, ushort, int, uint, long, ulong, longlong,
> ulonglong, float, double, longdouble)*2#
> */
>
> Note that  is not the same as +. Also note that subtract is implemented as
> xor.
I'm not sure why you're showing me numpy C code. I am talking about
the Python bools True and False. Because I'm talking about ufuncs. The original question was about ufuncs and, since array booleans are not treated as numbers for ordinary arithmetic, the question was when *do* we treat them as numbers. I'm a bugger for consistency and booleans aren't consistent.
Chuck
_______________________________________________
Numpydiscussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpydiscussion


On Sat, May 24, 2008 at 7:36 PM, Robert Kern < [hidden email]> wrote:
> On Sat, May 24, 2008 at 9:28 PM, Keith Goodman < [hidden email]> wrote:
>> I think it's interesting how python and numpy bools behave differently.
>>
>>>> x = np.array([True, True], dtype=bool)
>>>> x[0] + x[1]
>> True
>>>> x[0] & x[1]
>> True
>>>>
>>>> x = [True, True]
>>>> x[0] + x[1]
>> 2
>>>> x[0] & x[1]
>> True
>
> The difference arises straightforwardly from the principle that numpy
> tries not to upcast when you do an operation on two arrays of the same
> dtype; True+True==True is of somewhat more use than True+True==False.
> Python bools are just ints subclasses to give a nice string
> representation.
Sounds like there is no perfect solution. I like it the way it is but
these are differences I never noticed.
>> x = np.array([True, True], dtype=bool)
>> x.sum()
2
>> x[0] + x[1]
True
_______________________________________________
Numpydiscussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpydiscussion


On Sat, May 24, 2008 at 9:46 PM, Keith Goodman < [hidden email]> wrote:
> On Sat, May 24, 2008 at 7:36 PM, Robert Kern < [hidden email]> wrote:
>> On Sat, May 24, 2008 at 9:28 PM, Keith Goodman < [hidden email]> wrote:
>>> I think it's interesting how python and numpy bools behave differently.
>>>
>>>>> x = np.array([True, True], dtype=bool)
>>>>> x[0] + x[1]
>>> True
>>>>> x[0] & x[1]
>>> True
>>>>>
>>>>> x = [True, True]
>>>>> x[0] + x[1]
>>> 2
>>>>> x[0] & x[1]
>>> True
>>
>> The difference arises straightforwardly from the principle that numpy
>> tries not to upcast when you do an operation on two arrays of the same
>> dtype; True+True==True is of somewhat more use than True+True==False.
>> Python bools are just ints subclasses to give a nice string
>> representation.
>
> Sounds like there is no perfect solution. I like it the way it is but
> these are differences I never noticed.
>
>>> x = np.array([True, True], dtype=bool)
>>> x.sum()
> 2
Yes, the default accumulator dtype for integer types is at least the
size of the native int type, so we don't have the situation of
"bool+bool=bool".

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
_______________________________________________
Numpydiscussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpydiscussion


On Sat, May 24, 2008 at 8:48 PM, Robert Kern < [hidden email]> wrote:
On Sat, May 24, 2008 at 9:46 PM, Keith Goodman < [hidden email]> wrote:
> On Sat, May 24, 2008 at 7:36 PM, Robert Kern < [hidden email]> wrote:
>> On Sat, May 24, 2008 at 9:28 PM, Keith Goodman < [hidden email]> wrote:
>>> I think it's interesting how python and numpy bools behave differently.
>>>
>>>>> x = np.array([True, True], dtype=bool)
>>>>> x[0] + x[1]
>>> True
>>>>> x[0] & x[1]
>>> True
>>>>>
>>>>> x = [True, True]
>>>>> x[0] + x[1]
>>> 2
>>>>> x[0] & x[1]
>>> True
>>
>> The difference arises straightforwardly from the principle that numpy
>> tries not to upcast when you do an operation on two arrays of the same
>> dtype; True+True==True is of somewhat more use than True+True==False.
>> Python bools are just ints subclasses to give a nice string
>> representation.
>
> Sounds like there is no perfect solution. I like it the way it is but
> these are differences I never noticed.
>
>>> x = np.array([True, True], dtype=bool)
>>> x.sum()
> 2
Yes, the default accumulator dtype for integer types is at least the
size of the native int type, so we don't have the situation of
"bool+bool=bool".
How about
In [14]: x += 5
In [15]: x Out[15]: array([ True, True], dtype=bool)
In [16]: x.tostring() Out[16]: '\x01\x01'
In [17]: x + 5
Out[17]: array([6, 6])
In [18]: (x + 5).dtype Out[18]: dtype('int32')
In [19]: (x.astype(int8) + 5).dtype Out[19]: dtype('int8')
I have to write tests for 64 of these buggers and some poor sod has to write the documentation. All these inconsistencies are going to drive both of us mad.
Chuck
_______________________________________________
Numpydiscussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpydiscussion


On Sat, May 24, 2008 at 9:45 PM, Charles R Harris
< [hidden email]> wrote:
>> I'm not sure why you're showing me numpy C code. I am talking about
>> the Python bools True and False.
>
> Because I'm talking about ufuncs. The original question was about ufuncs
> and, since array booleans are not treated as numbers for ordinary
> arithmetic, the question was when *do* we treat them as numbers. I'm a
> bugger for consistency and booleans aren't consistent.
And I brought up the Python bools because there is a relationship that
numpy has with the rest of Python's types that we need to keep in
mind.
I think it boils down to this: when we have places where bools are
operated with bools and expect to output bools, we can decide what the
rules are. For the arithmetic operations +*, there are reasonable
Boolean logic interpretations that we can apply.
When upcasting is requested, either implicitly or explicitly, they
turn into 1s and 0s. All of the behaviors you think are inconsistent
just arise from the consistent application of that simple rule. Since
it *is* sometimes useful to treat booleans as numerical 1s and 0s, I
think it would be a mistake to prevent it. Sure, it doesn't really
make sense to do sin(True), but if you want to preserve the useful
behaviors, you will just end up with a big list of special cases and
make behavior difficult to reason about.

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
_______________________________________________
Numpydiscussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpydiscussion


On Sat, May 24, 2008 at 9:57 PM, Charles R Harris
< [hidden email]> wrote:
> How about
>
> In [14]: x += 5
>
> In [15]: x
> Out[15]: array([ True, True], dtype=bool)
Output = bool.
> In [16]: x.tostring()
> Out[16]: '\x01\x01'
>
>
> In [17]: x + 5
> Out[17]: array([6, 6])
Output != bool.
> In [18]: (x + 5).dtype
> Out[18]: dtype('int32')
>
> In [19]: (x.astype(int8) + 5).dtype
> Out[19]: dtype('int8')
>
> I have to write tests for 64 of these buggers and some poor sod has to write
> the documentation. All these inconsistencies are going to drive both of us
> mad.
They aren't inconsistent in the slightest. They follow from a very simple rule.

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
_______________________________________________
Numpydiscussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpydiscussion


On Sat, May 24, 2008 at 8:59 PM, Robert Kern < [hidden email]> wrote:
On Sat, May 24, 2008 at 9:45 PM, Charles R Harris
>> I'm not sure why you're showing me numpy C code. I am talking about
>> the Python bools True and False.
>
> Because I'm talking about ufuncs. The original question was about ufuncs
> and, since array booleans are not treated as numbers for ordinary
> arithmetic, the question was when *do* we treat them as numbers. I'm a
> bugger for consistency and booleans aren't consistent.
And I brought up the Python bools because there is a relationship that
numpy has with the rest of Python's types that we need to keep in
mind.
I think it boils down to this: when we have places where bools are
operated with bools and expect to output bools, we can decide what the
rules are. For the arithmetic operations +*, there are reasonable
Boolean logic interpretations that we can apply.
When upcasting is requested, either implicitly or explicitly, they
turn into 1s and 0s. All of the behaviors you think are inconsistent
just arise from the consistent application of that simple rule. Since
it *is* sometimes useful to treat booleans as numerical 1s and 0s, I
think it would be a mistake to prevent it. Sure, it doesn't really
make sense to do sin(True), but if you want to preserve the useful
behaviors, you will just end up with a big list of special cases and
make behavior difficult to reason about.
So what about the rule that the array type takes precedence over the scalar type? That is broken for booleans.
Chuck
_______________________________________________
Numpydiscussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpydiscussion


On Sat, May 24, 2008 at 10:02 PM, Charles R Harris
< [hidden email]> wrote:
> So what about the rule that the array type takes precedence over the scalar
> type? That is broken for booleans.
Yes, and if it wasn't an intentional special case (I don't recall
discussing it on the list, but it might have been), then it's a bug
and suitable for changing. The other behaviors are intentional and
thus not suitable for changing.

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
_______________________________________________
Numpydiscussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpydiscussion


On Sat, May 24, 2008 at 10:06 PM, Robert Kern < [hidden email]> wrote:
> On Sat, May 24, 2008 at 10:02 PM, Charles R Harris
> < [hidden email]> wrote:
>> So what about the rule that the array type takes precedence over the scalar
>> type? That is broken for booleans.
>
> Yes, and if it wasn't an intentional special case (I don't recall
> discussing it on the list, but it might have been), then it's a bug
> and suitable for changing. The other behaviors are intentional and
> thus not suitable for changing.
Nope, I'm wrong. I just doublechecked the manual. bool_ is separate
from number on the tree of dtypes, so bool_ + int_ is a crosskind
operation and the scalarness of the int_ is not a concern. E.g.
array([1, 2]) + 3.0 has similar behavior. This is not an
inconsistency.

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
_______________________________________________
Numpydiscussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpydiscussion


On Sat, May 24, 2008 at 9:06 PM, Robert Kern < [hidden email]> wrote:
On Sat, May 24, 2008 at 10:02 PM, Charles R Harris
> So what about the rule that the array type takes precedence over the scalar
> type? That is broken for booleans.
Yes, and if it wasn't an intentional special case (I don't recall
discussing it on the list, but it might have been), then it's a bug
and suitable for changing. The other behaviors are intentional and
thus not suitable for changing.
So how do we know which is which? How does one write a test for an unspecified behavior? And it is clear that add.reduce breaks the rules for booleans. The result is that the boolean add function doesn't in fact *have* a reduce method.
Chuck
_______________________________________________
Numpydiscussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpydiscussion


On Sat, May 24, 2008 at 9:11 PM, Robert Kern < [hidden email]> wrote:
On Sat, May 24, 2008 at 10:06 PM, Robert Kern < [hidden email]> wrote:
> On Sat, May 24, 2008 at 10:02 PM, Charles R Harris
> < [hidden email]> wrote:
>> So what about the rule that the array type takes precedence over the scalar
>> type? That is broken for booleans.
>
> Yes, and if it wasn't an intentional special case (I don't recall
> discussing it on the list, but it might have been), then it's a bug
> and suitable for changing. The other behaviors are intentional and
> thus not suitable for changing.
Nope, I'm wrong. I just doublechecked the manual. bool_ is separate
from number on the tree of dtypes, so bool_ + int_ is a crosskind
operation and the scalarness of the int_ is not a concern. E.g.
array([1, 2]) + 3.0 has similar behavior. This is not an
inconsistency.
You are confusing promotion between kinds with promotion within kinds. So in this view, bool is not an integer type.
Chuck
_______________________________________________
Numpydiscussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpydiscussion

12
