[Numpy-discussion] Rationale for integer promotion rules

[Nathaniel Smith]

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.

> Is there a rationale somewhere documenting and explaining this behaviour
> (sorry if I've missed it in a obvious location)? Is it the produce of
> organic evolution?
>
> Also, it is set to stay like this, or will it evolve in the future?

I don't know -- if you make a good case for something better then maybe?

-n

-- 
Nathaniel J. Smith -- http://vorpus.org