[Numpy-discussion] Default type for functions that accumulate integers

[Charles R Harris]

On Tue, Jan 3, 2017 at 10:08 AM, Sebastian Berg <sebastian at 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.harris at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20170103/021f8beb/attachment.html>