@rgommers wrote on 2012-05-19

Likely related to #2350.

This is unrelated to #2350; the overflow checking code for floating point and integers is totally different. (The former relies on some special IEEE-754 features that can only be accessed through platform specific code and #2350 is that apparently our platform specific code is buggy; integer overflow is checked directly by hand in our own C code. grep for npy_set_floatstatus_overflow in scalarmathmodule.c.src to see...)

The bug here is very simple: we have two complete sets of arithmetic functions for integers, one in scalarmathmodule.c.src and one in loops.c.src. The former code implements overflow checking, the latter code doesn't. We should just fix this. (Ideally by moving the checks into loops.c.src and then throwing out scalarmathmodule.c.src entirely, I guess -- the ufunc loops have a funny calling convention if you're in a scalar, but so what. There's still no reason you can't call them directly to implement scalar arithmetic and I can't imagine that doing a 1-element for loop is measurably slower than using a custom function that has just taken out the for loop.)

I presume in addition to int32, this bug can be generalised to cover the other integer types, e.g. uint8 (as shown in my example below), int8, uint16, int16, uint32, int64, uint64

>>> import numpy as np
>>> np.__version__
'1.6.1'
>>> A = np.zeros((100,100), np.uint8) # Matrix could be very big
>>> A[3,4] = 255 # Max value, setting up next step in example
>>> A[3,4]
255
>>> A[3,4] += 1 # Silently overflows on NumPy 1.6
>>> A[3,4]
0

In this use case, I am working with the topology of a graph allowing multiple edges held as an integer adjacency matrix, A. I would calculate things like A^n for paths of length n, and also make changes to A directly (e.g. adding edges). The motivation to use the low range types like np.uint8 (unsigned) is to limit the memory while working with large networks. In this usage I do not need negative entries.

See http://mail.scipy.org/pipermail/numpy-discussion/2013-January/064948.html and http://mail.scipy.org/pipermail/numpy-discussion/2013-January/064949.html

@peterjc: Right, if you look at scalarmathmodule.c.src and loops.c.src you'll see that all that the code for all the different integer widths is generated from the same template, so whatever applies to one width applies to all.

duplicate of #8987, since there is more discussion there should we close this one?

Closing as duplicate of gh-8987 as mentioned already by Matti (integer overflow issue).