Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Silent overflow in absolute()

See original GitHub issue

Python:

In [117]: abs(-2147483646)
Out[117]: 2147483646

In [118]: abs(-2147483647)
Out[118]: 2147483647

In [119]: abs(-2147483648)
Out[119]: 2147483648L

In [120]: abs(-2147483649)
Out[120]: 2147483649L

In [121]: abs(-2147483650)
Out[121]: 2147483650L

NumPy:

In [93]: absolute(array([-2147483646]))
Out[93]: array([2147483646])

In [94]: absolute(array([-2147483647]))
Out[94]: array([2147483647])

In [95]: absolute(array([-2147483648]))
Out[95]: array([-2147483648])

In [96]: absolute(array([-2147483649]))
Out[96]: array([2147483649], dtype=int64)

In [97]: absolute(array([-2147483650]))
Out[97]: array([2147483650], dtype=int64)

In C this is undefined because abs() returns an int and there’s no +2147483648, but NumPy should convert to int64? and then absolute(array(-2**63)) should convert to object array with longs instead of returning -9223372036854775808?

Issue Analytics

State:
Created 9 years ago
Comments:9 (9 by maintainers)

Top GitHub Comments

2reactions

njsmithcommented, Jul 26, 2017

It’s awful, but all integer overflow cases are awful; is this one so much worse that it needs special cases like this? (I don’t know the answer. Having proper integer overflow detection in general would certainly help some in this case and many others, though.)

2reactions

matthew-brettcommented, Jul 26, 2017

Sure - but I think that risk (of type promotion when using uints) is way less bad than returning a negative number from (u)abs…