[Numpy-discussion] Rationale for integer promotion rules

[Matthew Brett]

On Thu, Jul 16, 2015 at 7:14 PM, Nathaniel Smith <njs at pobox.com> wrote:
> On Thu, Jul 16, 2015 at 9:18 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>>
>> Hi,
>>
>> We were discussion integer promotion rules amongst the Numba team, and
>> we were wondering about the rationale for Numpy's rules.  For example,
>> adding int8 and int8 will give int8 as result (with potential
>> magnitude loss),
>
> I believe the motivation here is that if the user took the trouble to
> set up int8 arrays, they probably actually want int8 arrays -- it
> would be annoying if int8 + int8 -> int16 (doubling memory use), and
> presumably also imply that int8 + int8 + int8 -> int32, and then what
> does add.reduce do? Not to mention int64 + int64.
>
> My guess is that while the possibility of overflow is something of a
> problem, the solution to that is to make it easy to catch overflow and
> warn/error, rather than trying to define the casting rules so that it
> can't happen.
>
>> while adding int8 and uint8 will give int16 as result
>> (promoting to the smallest fitting type).
>
> I understand this to be a consequence of the previous rule (results
> should match inputs) combined with the need to find a common input
> type.
>
>>  Furthermore, adding int64
>> and uint64 returns float64.
>
> This is a grievous kluge, on the grounds that no-one is really sure
> *what* to do in this case.

It doesn't seem unreasonable to me : casting int64 to uint64 or uint64
to int64 could lead to disastrous truncation.  float64 can exactly
represent integers +/- 2**53 and will have some defined relative error
above that.

Cheers,

Matthew