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.

ulong_max=18446744073709551615
type(ulong_max) <type 'long'> print ulong_max 18446744073709551615 very_long_long=18446744073709551615184467440737095 51615
type(very_long_long) <type 'long'> print very_long_long 1844674407370955161518446744073709551615 result=very_long_long/15
type(result) <type 'long'> print result 122978293824730344101229782938247303441

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):

print 17**100

11088993727807836413061117158750949664360171676498 79524402769841278887580501366697712424694256005093 589248451503068397608001

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]

"S.Susnjar" <fo***@gmx.de> wrote in message
news:ba*************************@posting.google.co m...

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]

On Tue, 18 Nov 2003 21:45:45 -0500, "Terry Reedy" <tj*****@udel.edu> wrote:

"S.Susnjar" <fo***@gmx.de> wrote in message
news:ba*************************@posting.google.c om...

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

Seems out of date re version 2.3.2:

x = 2**30
x 1073741824 type(x) <type 'int'> x+x 2147483648L type(x+x)

<type 'long'>

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
operations. Ugh! Barf!</rant>.
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