FW: [Numpy-discussion] Bug: extremely misleading array behavior

Perry Greenfield perry at stsci.edu
Thu Jun 6 13:30:02 EDT 2002

[I thought I replied yesterday, but somehow that apparently vanished.]

<Konrad Hinsen writes>: 
> "Perry Greenfield" <perry at stsci.edu> writes:
> > Numarray has different coercion rules so that this doesn't
> > happen. Thus one doesn't need c[1,1] to give a rank-0 array.
> What are those coercion rules?
For binary operations between a Python scalar and array, there is
no coercion performed on the array type if the scalar is of the
same kind as the array (but not same size or precision). For example
(assuming ints happen to be 32 bit in this case)

Python Int (Int32) * Int16 array --> Int16 array
Python Float (Float64) * Float32 array --> Float32 array. 

But if the Python scalar is of a higher kind, e.g., Python float
scalar with Int array, then the array is coerced to the corresponding
type of the Python scalar.

Python Float (Float64) * Int16 array --> Float64 array.
Python Complex (Complex64) * Float32 array --> Complex64 array. 

Numarray basically has the same coercion rules as Numeric when two
arrays are involved (there are some extra twists such as:

UInt16 array * Int16 array --> Int32 array

since neither input type is a proper subset of the other. (But since
Numeric doesn't (or didn't until Travis changed that) have unsigned
types, that wouldn't have been an issue with Numeric.)

> > (if that isn't too hard to implement). Of course you get into
> > backward compatibility issues. But really, to get it right, some
> > incompatibility is necessary if you want to eliminate this particular
> > wart.
> For a big change such as Numarray, I'd accept some incompatibilities.
> For just a new version of NumPy, no. There is a lot of code out there
> that uses NumPy, and I am sure that a good part of it relies on the
> current coercion rules. Moreover, there is no simple way to detect
> code that depends on coercion rules, so adapting existing code would
> be an enormous amount of work.
Certainly. I didn't mean to minimize that. But the current coercion
rules have produced a demand for solutions to the problem of upcasting,
and I consider those solutions to be less than ideal (savespace and
rank-0 arrays). If people really are troubled by these warts, I'm
arguing that the real solution is in changing the coercion behavior.
(Yes, it would be easiest to deal with if Python had all these types,
but I think that will never happen, nor should it happen.)


More information about the NumPy-Discussion mailing list