Repository navigation
uint64 modulo arithmetic broken (Trac #1940) #2533
Description
Original ticket http://projects.scipy.org/numpy/ticket/1940 on 2011-08-22 by trac user AngerMCS, assigned to unknown.
Running numpy 1.6.0 on python 3.2.1 both compiled from source.
uint64(-1)%2 is returning 0.0 which is obviously incorrect.
Also when using uint64, modulo is returning a a float64 which is illogical since it can never return anything other than a uint64.
Python 3.2.1 (default, Jul 20 2011, 15:59:19)
[GCC 4.3.2 20081105 (Red Hat 4.3.2-7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
from numpy import uint64
uint64(-1)
18446744073709551615
a = uint64(-1)
a
18446744073709551615
hex(a)
'0xffffffffffffffff'
a%2
0.0
Activity
numpy-gitbot commentedon Oct 19, 2012
@charris wrote on 2011-08-22
I suspect this is another case of the 2 being treated as signed, hence the promotion to float64, which has insufficient precision. This also shows up in the shift operators, but there things are (were) promoted to objects. These ufuncs probably need special treatment of their arguments.
numpy-gitbot commentedon Oct 19, 2012
@charris wrote on 2011-08-22
Note:
So probably what should happen in the original case is an error message on account of the promotion of kinds.
numpy-gitbot commentedon Oct 19, 2012
@mwiebe wrote on 2011-08-22
I've got things rigged up now so each ufunc can define its own type promotion function, see here:
https://github.com/m-paradox/numpy/blob/missingdata/numpy/core/include/numpy/ufuncobject.h#L191
This can probably be special-cased using this mechanism.
charris commentedon Feb 21, 2014
Need to look into that...
seberg commentedon Nov 19, 2022
Closing in favor of the linked gh-12525: This is a promotion issue.