[Numpy-discussion] Do we want scalar casting to behave as it does at the moment?
Matthew Brett
matthew.brett@gmail....
Tue Jan 8 10:59:17 CST 2013
Hi,
On Mon, Jan 7, 2013 at 10:58 PM, Andrew Collette
<andrew.collette@gmail.com> wrote:
> Hi,
>
>> 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
>> me.
>
> Yes, I think this (the 1.5 overflow behavior) was a bit odd, if easy
> to understand.
>
>> For 1) - of course the upcasting in 1.6 is only going to work some of
>> the time. For example:
>>
>> In [2]: np.array([127], dtype=np.int8) * 1000
>> Out[2]: 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
> addition.
>
> 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.
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.
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.
Best,
Matthew
More information about the NumPy-Discussion
mailing list