[Numpy-discussion] Scalar coercion
Charles R Harris
Thu Mar 1 18:39:49 CST 2007
On 3/1/07, Travis Oliphant <email@example.com> wrote:
> A ticket was posted that emphasizes that the current behavior of NumPy
> with regards to scalar coercion is different than numarray's behavior.
> If we were pre 1.0, I would probably change the behavior to be in-line
> with numarray. But, now I think it needs some discussion because we are
> changing the behavior of a released version of NumPy and we need some
> more conservatism in how changes happen.
> If we can classify the current behavior as a bug then we can change it.
> Otherwise, I'm concerned.
> The behavior has to do with a mixed scalar/array computation. NumPy
> does not let scalars (equivalently 0-d arrays) determine the output type
> of the array operation, *unless* the scalar is of a fundamentally
> different kind (i.e. the array is an integer-type but the scalar is a
> floating-point type). In this case, the current behavior is to coerce
> the array to the smallest-type in that general category of scalars.
> The reason for this behavior is to make sure that
> array([1,2,3,4],int8)*10 returns an int8 (instead of an int32 because
> of how the 10 is interpreted by Python).
> The current behavior, however, also means that
> array([1,2,3,4],int8)*10.0 will return a float32 array.
> I think numarray would return a float64 array in this case (i.e. the
> type of the scalar would be honored when the coercion was between two
> different kinds of arrays).
I feel that the default types should be integer, float64, cfloat64, with the
other types for designer apps with special needs. However
Should coerce to float32, not float64, because whoever wrote it took the
trouble to be specific about the type for a reason. So I agree with the
change you propose and I doubt it will be noticed except by those who find
numpy behaving as they expect.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Numpy-discussion