[Numpy-discussion] Numeric/numarray compatibility issue

[Perry Greenfield]

On Mar 3, 2005, at 12:31 PM, konrad.hinsen at laposte.net wrote:

> Following a bug report concerning ScientificPython with numarray, I 
> noticed an incompatibility between Numeric and numarray, and I am 
> wondering if this is intentional.
>
> In Numeric, the result of a comparison operation is an integer array. 
> In numarray, it is a Bool array. Bool arrays seem to behave like Int8 
> arrays when arithmetic operations are applied. The net result is that
>
> 	print n.add.reduce(n.greater(n.arange(128), -1))
>
> yields -128, which is not what I would expect.
>
> I can see two logically coherent points of views:
>
> 1) The Numeric view: comparisons yield integer arrays, which may be 
> used freely in arithmetic.
>
> 2) The "logician's" view: comparisons yield arrays of boolean values, 
> on which no arithmetic is allowed at all, only logical operations.
>
> The first approach is a lot more pragmatic, because there are a lot of 
> useful idioms that use the result of comparisons in arithmetic, 
> whereas an array of boolean values cannot be used for much else than 
> logical operations.
>
> And now for my pragmatic question: can anyone come up with a solution 
> that will work under both Numeric an numarray, won't introduce a speed 
> penalty under Numeric, and won't leave the impression that the 
> programmer had had too many beers?  There is the quick hack
>
> 	print n.add.reduce(1*n.greater(n.arange(128), -1))
>
> but it doesn't satisfy the last two criteria.

First of all, isn't the current behavior a little similar to Python in 
that Python Booleans aren't pure either (for backward compatibility 
purposes)?

I think this has come up in the past, and I thought that one possible 
solution was to automatically coerce all integer reductions and 
accumulations to Int32 to avoid overflow issues. That had been 
discussed before and apparently many preferred avoiding automatic 
promotion (the reductions allow specifying a new type for the 
reduction, but I don't believe that helps your specific example for 
code that works for both). Using .astype(Int32) should work for both, 
right? (or is that too much of a speed hit?) But it is a fair question 
to ask if arithmetic operations should be allowed on booleans without 
explicit casts.

Perry