On Thu, Jul 16, 2015 at 7:14 PM, Nathaniel Smith <n...@pobox.com> wrote: > On Thu, Jul 16, 2015 at 9:18 AM, Antoine Pitrou <solip...@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 _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
