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