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

[Chris Barker - NOAA Federal]

On Thu, Jan 17, 2013 at 6:26 AM, Matthew Brett <matthew.brett at gmail.com> wrote:

> I am starting to wonder if we should aim for making
>
> * scalar and array casting rules the same;
> * Python int / float scalars become int32 / 64 or float64;

aren't they already? I'm not sure what you are proposing.

> This has the benefit of being very easy to understand and explain.  It
> makes dtypes predictable in the sense they don't depend on value.

That is key -- I don't think casting should ever depend on value.

> Those wanting to maintain - say - float32 will need to cast scalars to float32.
>
> Maybe the use-cases motivating the scalar casting rules - maintaining
> float32 precision in particular - can be dealt with by careful casting
> of scalars, throwing the burden onto the memory-conscious to maintain
> their dtypes.

IIRC this is how it worked "back in the day" (the Numeric day? -- and
I'm pretty sure that in the long run it worked out badly. the core
problem is that there are only python literals for a couple types, and
it was oh so easy to do things like:

my_arr = np,zeros(shape, dtype-float32)

another_array = my_array * 4.0

and you'd suddenly get a float64 array. (of course, we already know
all that..) I suppose this has the up side of being safe, and having
scalar and array casting rules be the same is of course appealing, but
you use a particular size dtype for a reason,and it's a real pain to
maintain it.

Casual users will use the defaults that match the Python types anyway.

So in the in the spirit of "practicality beats purity" -- I"d like
accidental upcasting to be hard to do.

-Chris

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov