[Numpy-discussion] Change in scalar upcasting rules for 1.6.x?

Francesc Alted francesc@continuum...
Tue Feb 14 07:16:38 CST 2012


On Feb 14, 2012, at 1:47 PM, Charles R Harris wrote:
<clip>
> About the behavior in question, I would frame this as a specific case with argument for and against like so:
> 
> The Current Behavior
> 
> In [1]: array([127], int8) + 127
> Out[1]: array([-2], dtype=int8)
> 
> In [2]: array([127], int8) + 128
> Out[2]: array([255], dtype=int16)
> 

Good point.

> Arguments for Old Behavior
> 
> Predictable, explicit output type. This is a good thing, in that no one wants their 8GB int8 array turning into a 16GB int16 array.

Exactly, IIRC this is the main reason why the old behavior was decided.

> Backward compatibility.
> 
> Arguments for New Behavior
> 
> Fewer overflow problems. But no cure.
> 
> 
> Put that way I think you can make a solid argument for a tweak to restore old behavior. Overflow can be a problem, but partial cures are not going to solve it. I think we do need a way to deal with overflow. Maybe in two ways. 1) saturated operations, i.e., 127 + 128 -> 127. This might be good for images. 2) raise an error. We could make specific ufuncs for these behaviors.

Hmm, I'm thinking that it would be nice if NumPy could actually support both behaviors.  I just wonder whether that should be implemented as a property of each array or as global attribute for the whole NumPy package.  While the latter should be easier to implement (what to do when different behaved arrays are being operated?), the former would give more flexibility.  I know, this will introduce more complexity in the code base, but anyway, I think that would be a nice thing to support for NumPy 2.0.

Just a thought,

-- Francesc Alted





More information about the NumPy-Discussion mailing list