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



_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Reply via email to