<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 3, 2017 at 10:08 AM, Sebastian Berg <span dir="ltr"><<a href="mailto:sebastian@sipsolutions.net" target="_blank">sebastian@sipsolutions.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mo, 2017-01-02 at 18:46 -0800, Nathaniel Smith wrote:<br>
> On Mon, Jan 2, 2017 at 6:27 PM, Charles R Harris<br>
> <<a href="mailto:charlesr.harris@gmail.com">charlesr.harris@gmail.com</a>> wrote:<br>
> ><br>
> > Hi All,<br>
> ><br>
> > Currently functions like trace use the C long type as the default<br>
> > accumulator for integer types of lesser precision:<br>
> ><br>
<br>
</span><snip><br>
<span class=""><br>
><br>
> Things we'd need to know more about before making a decision:<br>
> - compatibility: if we flip this switch, how much code breaks? In<br>
> general correct numpy-using code has to be prepared to handle<br>
> np.dtype(int) being 64-bits, and in fact there might be more code<br>
> that<br>
> accidentally assumes that np.dtype(int) is always 64-bits than there<br>
> is code that assumes it is always 32-bits. But that's theory; to know<br>
> how bad this is we would need to try actually running some projects<br>
> test suites and see whether they break or not.<br>
> - speed: there's probably some cost to using 64-bit integers on 32-<br>
> bit<br>
> systems; how big is the penalty in practice?<br>
><br>
<br>
</span>I agree with trying to switch the default in general first, I don't<br>
like the idea of having two different "defaults".<br>
<br>
There are two issues, one is the change on Python 2 (no inheritance of<br>
Python int by default numpy type) and any issues due to increased<br>
precision (more RAM usage, code actually expects lower precision<br>
somehow, etc.).<br>
Cannot say I know for sure, but I would be extremely surprised if there<br>
is a speed difference between 32bit vs. 64bit architectures, except the<br>
general slowdown you get due to bus speeds, etc. when going to higher<br>
bit width.<br>
<br>
If the inheritance for some reason is a bigger issue, we might limit<br>
the change to Python 3. For other possible problems, I think we may<br>
have difficulties assessing how much is affected. The problem is, that<br>
the most affected thing should be projects only being used on windows,<br>
or so. Bigger projects should work fine already (they are more likely<br>
to get better due to not being tested as well on 32bit long platforms,<br>
especially 64bit windows).<br>
<br>
Of course limiting the change to python 3, could have the advantage of<br>
not affecting older projects which are possibly more likely to be<br>
specifically using the current behaviour.<br>
<br>
So, I would be open to trying the change, I think the idea of at least<br>
changing it in python 3 has been brought up a couple of times,<br>
including by Julian, so maybe it is time to give it a shot....<br>
<br>
It would be interesting to see if anyone knows projects that may be<br>
affected (for example because they are designed to only run on windows<br>
or limited hardware), and if avoiding to change anything in python 2<br>
might mitigate problems here as well (additionally to avoiding the<br>
inheritance change)?<br></blockquote><div><br></div><div>There have been a number of reports of problems due to the inheritance stemming both from the changing precision and, IIRC, from differences in print format or some such. So I don't expect that there will be no problems, but they will probably not be difficult to fix.<br><br></div><div>Chuck <br></div></div></div></div>