[Python-bugs-list] [Bug #122113] Mathematic operations fail on maximum negative integer
noreply@sourceforge.net
noreply@sourceforge.net
Tue, 14 Nov 2000 13:38:11 -0800
Bug #122113, was updated on 2000-Nov-10 02:43
Here is a current snapshot of the bug.
Project: Python
Category: Core
Status: Closed
Resolution: Invalid
Bug Group: Not a Bug
Priority: 3
Summary: Mathematic operations fail on maximum negative integer
Details: Python documentation states -2147483648 is the largest maximum negative integer value. When attempting mathematical comparisons on this value an overflow error is encountered. The following line will fail:
if -2147483648 < 50:
print 'broken'
However assigning this value to a variable and using the variable in the comparison will succeed as will the following:
maximum = -2147483648
int(maximum)
This was originally found in 1.5.2 but I have tested it in 2.0 and the problem is still present.
Follow-Ups:
Date: 2000-Nov-10 05:14
By: gvanrossum
Comment:
Any expression involving -2147483648 (via a variable or otherwise) immediately raises OverflowError for me, as it should and as it explicitly is coded.
Are there other operations on integers that fail for you?
What platform are you using? How many bits is a long int in C on that platform?
Does the test suite ("make test") complete without errors?
Did you build Python yourself or did you download a binary from somewhere?
Did you get any errors or warnings during building?
Assigned to Tim Peters, our expert on numerical conundrums.
-------------------------------------------------------
Date: 2000-Nov-10 05:41
By: rhathaway
Comment:
Its just a guess but I think I should have added slightly more information on the bug -> I'll remember for the future ;-)
The heart of the problem is that the int() function works with -2147483648 but mathematical operations do not. Should the maximum number be -2147483648 or -2147483647 -> Python appears to be unsure atm. Basically I receive a value in a string and I need to convert it into an appropriate Python type to work with it. To do this I am currently issuing an int(stringValue) and trapping on Value error at which point I attempt to convert it to a long. Now the int works with
-2147483648 so the value is converted to an int type but the subsequent less than check fails.
The problem only occurs with this single value at the very bottom of the integer range. I have not come across any other values that cause similar problems.
I have tested this problem in both 1.5.2 and 2.0 (Python on both Windows 98 and on Solaris 2.7. The windows Python installation was from the self installing exe downloaded from the python website. The solaris install was built from the tar file downloaded from the python website. No installation problems were encountered in any of the installs and the test suite make works fine.
Hopefully this should help to clarify the issue I have raised
Kind regards
Rob
-------------------------------------------------------
Date: 2000-Nov-10 10:17
By: tim_one
Comment:
Rob, please post a specific line of actual Python code that fails for you, self-contained and without trying to explain it to us <wink>.
The literal -2147483648 in a Python program on a 32-bit machine *should* raise OverflowError at compile-time. Here's an actual screen dump (from IDLE) showing this:
>>> x = -2147483648
OverflowError: integer literal too large
>>>
For that reason, none of your examples make sense: if we try *any* of them, they simply die with the same kind of OverflowError.
Note however that this does *not* fail:
>>> x = int("-2147483648")
>>> x
-2147483648
>>>
The difference in behavior here is unfortunate, but is a fact of life: in the case of a literal appearing within Python program text, Python's grammar does not consider the leading "-" to be part of the literal. -4 is actually read by Python as applying the unary negation operator to the positive integer 4. That's why -2147483648 *as a literal* blows up: the 2147483648 part alone is too large. In the case of int(string), the string is parsed as a whole by a C library routine, which knows what to do with "-2147483648".
As to your test case:
if -2147483648 < 50: print 'broken'
First, let's actually run it:
>>> if -2147483648 < 50: print 'broken'
OverflowError: integer literal too large
>>>
As explained above, that's exactly what's expected. Second, let's try it via int(string) instead:
>>> if int("-2147483648") < 50: print 'broken'
broken
>>>
Yes, it prints "broken", but that's what it SHOULD print: if you agree that 0 < 50, and that -1 < 50, then certainly you must agree that -2147483648 < 50 is correct too.
In short, I don't see any bug here, and suspect you're wrestling with illusions. Unless you can give us a specific piece of runnable self-contained Python code that shows a bug, I'll just close this report as a Not-a-Bug.
-------------------------------------------------------
Date: 2000-Nov-13 02:57
By: rhathaway
Comment:
Tim,
It is true that having different parts of Python treat the value of -2147483648 differently can make writing programs difficult. I guess it would be fair to say that it is the way the the int() function (and therefore underlying C library routine) deals with the value. If you send the function the literal of -2147483648 it errors out (as expected) however if you send it the string value of '-2147483648' it will succeed. It is this behaviour that is at the root of the problem. Unfortunately I only have a string representation of the value and the routine I have written attempts to figure out which of the Python types it should be converted to in order to perform some calculations on it.
I'm willing to accept suggestions as how to convert from a string into the correct Python type in order to perform the relevant calculations.
Many thanks for your help
rob
-------------------------------------------------------
Date: 2000-Nov-13 14:24
By: tim_one
Comment:
Rob, as far as I can tell, conversion from string to int already works exactly the way you want it to.
If you're still having a problem, please include an actual, self-contained, executable Python example.
-------------------------------------------------------
Date: 2000-Nov-14 13:38
By: tim_one
Comment:
Closing this, as there's still no evidence of a bug (although it is irritating that int literals have different rules via int() than via Python's grammar).
-------------------------------------------------------
For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=122113&group_id=5470