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

Dag Sverre Seljebotn d.s.seljebotn@astro.uio...
Tue Jan 8 15:32:42 CST 2013

On 01/08/2013 06:20 PM, Andrew Collette wrote:
> Hi,
>> I think you are voting strongly for the current casting rules, because
>> they make it less obvious to the user that scalars are different from
>> arrays.
> Maybe this is the source of my confusion... why should scalars be
> different from arrays?  They should follow the same rules, as closely

Scalars (as in, Python float/int) are inherently different because the 
user didn't specify a dtype.

For an array, there was always *some* point where the user chose, 
explicitly or implicitly, a dtype.

> as possible.  If a scalar value would fit in an int16, why not add it
> using the rules for an int16 array?

So you are saying that, for an array x, you want

x + random.randint(100000)

to produce an array with a random dtype?

So that after carefully testing that your code works, suddenly a 
different draw (or user input, or whatever) causes a different set of 
dtypes to ripple through your entire program?

To me this is something that must be avoided at all costs. It's hard 
enough to reason about the code one writes without throwing in complete 
randomness (by which I mean, types determined by values).

Dag Sverre

>> Returning to the question of 1.5 behavior vs the error - I think you
>> are saying you prefer the 1.5 silent-but-deadly approach to the error,
>> but I think I still haven't grasped why.  Maybe someone else can
>> explain it?  The holiday has not been good to my brain.
> In a strict choice between 1.5-behavior and errors, I'm not sure which
> one I would pick.  I don't think either is particularly useful.  Of
> course, other members of the community would likely have a different
> view, especially those who got used to the 1.5 behavior.
> Andrew
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion

More information about the NumPy-Discussion mailing list