[Numpy-discussion] Do we want scalar casting to behave as it does at the moment?

Andrew Collette andrew.collette@gmail....
Fri Jan 4 10:57:05 CST 2013


Hi,

> (sorry, no time for full reply, so for now just answering what I
> believe is the main point)

Thanks for taking the time to discuss/explain this at all... I appreciate it.

> The evilness lies in the silent switch between the rollover and upcast
> behavior, as in the example I gave previously:
>
>     In [50]: np.array([2], dtype='int8') + 127
>     Out[50]: array([-127], dtype=int8)
>     In [51]: np.array([2], dtype='int8') + 128
>     Out[51]: array([130], dtype=int16)

Right, but for better or for worse this is how *array* addition works.
 If I have an int16 array in my program, and I add a user-supplied
array to it, I get rollover if they supply an int16 array and
upcasting if they provide an int32.  The answer may simply be that we
consider scalar addition a special case; I think that's really what
tripping me up here.

Granted, one is a type-dependent change while the other is a
value-dependent change; but in my head they were connected by the
rules for choosing a "effective" dtype for a scalar based on its
value.

> If the scalar is the user-supplied value, it's likely you actually
> want a fixed behavior (either rollover or upcast) regardless of the
> numeric value being provided.

This is a good point; thanks.

> Looking at what other numeric libraries are doing is definitely a good
> suggestion.

I just double-checked IDL, and for addition it seems to convert to the
larger type:

a = bytarr(10)
help, a+fix(0)
<Expression>    INT       = Array[10]
help, a+long(0)
<Expression>    LONG      = Array[10]

Of course, IDL and Python scalars likely work differently.

Andrew


More information about the NumPy-Discussion mailing list