[Numpy-discussion] Do we want scalar casting to behave as it does at the moment?
Mon Jan 7 16:58:12 CST 2013
> Taking 2) first, in this example:
>> return self.f[dataset_name][...] + heightmap
> assuming it is not going to upcast, would you rather it overflow than
> raise an error? Why? The second seems more explicit and sensible to
Yes, I think this (the 1.5 overflow behavior) was a bit odd, if easy
> For 1) - of course the upcasting in 1.6 is only going to work some of
> the time. For example:
> In : np.array(, dtype=np.int8) * 1000
> Out: array([-4072], dtype=int16)
> So - you'll get something, but there's a reasonable chance you won't
> get what you were expecting. Of course that is true for 1.5 as well,
> but at least the rule there is simpler and so easier - in my opinion -
> to think about.
Part of what my first example was trying to demonstrate was that the
function author assumed arrays and scalars obeyed the same rules for
For example, if data were int8 and heightmap were an int16 array with
a max value of 32767, and the data had a max value in the same spot
with e.g. 10, then the addition would overflow at that position, even
with the int16 result. That's how array addition works in numpy, and
as I understand it that's not slated to change.
But when we have a scalar of value 32767 (which fits in int16 but not
int8), we are proposing instead to do nothing under the assumption
that it's an error.
In summary: yes, there are some odd results, but they're consistent
with the rules for addition elsewhere in numpy, and I would prefer
that to treating this case as an error.
Out of curiosity, I checked what IDL did, and it overflows using
something like the numpy 1.6 rules:
IDL> print, byte(1) + fix(32767)
and in other places with 1.5-like behavior:
IDL> print, byte(1) ^ fix(1000)
Of course, I don't hold up IDL as a shining example of good analysis
More information about the NumPy-Discussion