On Thu, Jan 17, 2013 at 6:26 AM, Matthew Brett
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@noaa.gov