Re: [Numpy-discussion] Rationale for integer promotion rules
Matthew Brett matthew.br...@gmail.com wrote: 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. We could promote to Python int on Python 3 and long on Python 2. Sturla ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Rationale for integer promotion rules
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
[Numpy-discussion] Rationale for integer promotion rules
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), while adding int8 and uint8 will give int16 as result (promoting to the smallest fitting type). Furthermore, adding int64 and uint64 returns float64. 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? Thank you Antoine. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Rationale for integer promotion rules
On Thu, 16 Jul 2015 19:19:58 +0100 Robert Kern robert.k...@gmail.com wrote: 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: 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. Specifically, when combining signed and unsigned ints, we need to find a signed int type that can simultaneously hold both of the *inputs*. I'm not sure that would be necessary for e.g. addition (as long as you run your code on a 2's complement machine). But thanks for the explanation. Regards Antoine. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Rationale for integer promotion rules
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. 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Rationale for integer promotion rules
On Thu, 16 Jul 2015 11:14:10 -0700 Nathaniel Smith n...@pobox.com wrote: 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? No, I was just wondering if it would be a good use of our time to try to use a scheme that looks remotely like Numpy's :-) Regards Antoine. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Rationale for integer promotion rules
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: 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. Specifically, when combining signed and unsigned ints, we need to find a signed int type that can simultaneously hold both of the *inputs*. Whether the *output* would fit or overflow is not what the rules are concerned with. -- Robert Kern ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
