maximum value for long?

[S.Susnjar]

Hello all,

I have been programming in Python only for a month or so and have stumbled
over a "problem" that I could not solve through rtfm.

$ python
Python 2.2.2 (#1, Nov 6 2003, 09:19:47)
[GCC 3.3] on irix646
Type "help", "copyright", "credits" or "license" for more information.
I have set ulong_max above to the C compilers ULONG_MAX definition from limits.h
I would have expected Python to complain when setting the value of the variable
very_long_long to anything greater than ULONG_MAX.
Since I am currently doing computations with integer values *much* bigger than
ULONG_MAX, this behaviour suites me, but I am wondering if this is a "standard"
Python behaviour since I do not want my scripts to become dependant on some
obscure non-standard feature...

Could any kind Python-Guru please shed some light on this?
Also, if Python really can handle longs that are bigger than the machines native
longs, the interpreter has to do some sort of arbitrary precision math
somewhere. Could you please point me to the according interpreter's source file(s)?

TIA + Regards,
S.Susnjar

 

[Skip Montanaro]

S> I have set ulong_max above to the C compilers ULONG_MAX definition
S> from limits.h I would have expected Python to complain when setting
S> the value of the variable very_long_long to anything greater than
S> ULONG_MAX. Since I am currently doing computations with integer
S> values *much* bigger than ULONG_MAX, this behaviour suites me, but I
S> am wondering if this is a "standard" Python behaviour since I do not
S> want my scripts to become dependant on some obscure non-standard
S> feature...

Python has a builtin unbounded long type. In 2.3, most (all?) operations on
integers will return longs if the op would overflow the machine's int
(typically 32- or 64-bits):
1108899372780783641306111715875094966436017167649879524402769841278887580501366697712424694256005093589248451503068397608001

S> Also, if Python really can handle longs that are bigger than the
S> machines native longs, the interpreter has to do some sort of
S> arbitrary precision math somewhere. Could you please point me to the
S> according interpreter's source file(s)?

Look at Objects/longobject.c in the source distribution.

Skip

 

[Terry Reedy]

Hello all,
Hi.

I have been programming in Python only for a month or so and have stumbled
over a "problem" that I could not solve through rtfm.

Ref Man 3.2 The standard type hierarchy
"
There are two types of integers:

Plain integers
These represent numbers in the range -2147483648 through 2147483647.
(The range may be larger on machines with a larger natural word size,
but not smaller.) When the result of an operation would fall outside
this range, the exception OverflowError is raised. For the purpose of
shift and mask operations, integers are assumed to have a binary, 2's
complement notation using 32 or more bits, and hiding no bits from the
user (i.e., all 4294967296 different bit patterns correspond to
different values).

Long integers
These represent numbers in an unlimited range, subject to available
(virtual) memory only. For the purpose of shift and mask operations, a
binary representation is assumed, and negative numbers are represented
in a variant of 2's complement which gives the illusion of an infinite
string of sign bits extending to the left.
"
In short, Python ints are C longs, while Python longs are extended or
arbitrary precision, and hence truly long. Your confusion over the
two meanings of 'long' is not unique among people with a C background
;-).

Terry J. Reedy

 

[Bengt Richter]

Ref Man 3.2 The standard type hierarchy
"
There are two types of integers:

Plain integers
These represent numbers in the range -2147483648 through 2147483647.
(The range may be larger on machines with a larger natural word size,
but not smaller.) When the result of an operation would fall outside
this range, the exception OverflowError is raised. For the purpose of

Seems out of date re version 2.3.2:

shift and mask operations, integers are assumed to have a binary, 2's
complement notation using 32 or more bits, and hiding no bits from the
user (i.e., all 4294967296 different bit patterns correspond to
different values).

Long integers
These represent numbers in an unlimited range, subject to available
(virtual) memory only. For the purpose of shift and mask operations, a
binary representation is assumed, and negative numbers are represented
in a variant of 2's complement which gives the illusion of an infinite
string of sign bits extending to the left.
"

Though <rant>hex of negative numbers is slated for ugliness (IMO) in version 2.4
in the form of '-' prefixing the hex of the absolute value -- making it useless
for the normal bit pattern visualization that one would like when looking at bitwise

In short, Python ints are C longs, while Python longs are extended or
arbitrary precision, and hence truly long. Your confusion over the
two meanings of 'long' is not unique among people with a C background
;-).

Regards,
Bengt Richter