[ python-Bugs-901285 ] random.randint fails for some ranges
SourceForge.net
noreply at sourceforge.net
Sat Feb 21 03:17:38 EST 2004
Bugs item #901285, was opened at 2004-02-20 14:27
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=901285&group_id=5470
Category: Python Library
Group: Python 2.2.2
Status: Open
>Resolution: Wont Fix
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: random.randint fails for some ranges
Initial Comment:
I want a random 32-bit int and do it the obvious way:
lowest, highest = int(-2**31), int(2**31-1)
r = random.randint(lowest, highest)
random.randint throws an exception:
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "/usr/lib/python2.2/random.py", line 349, in randint
return self.randrange(a, b+1)
File "/usr/lib/python2.2/random.py", line 328, in
randrange
raise ValueError, "empty range for randrange()"
ValueError: empty range for randrange()
----------------------------------------------------------------------
>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-02-21 03:17
Message:
Logged In: YES
user_id=80475
This has been fixed for Py2.3.3 and 2.4 as a result of the
automatic conversion between ints and longs.
In 2.2, it is still possible, but the call to int() inside
random.randrange() would be have to be changed to math.floor()
which can handle the full range. As the comments indicate,
this was not worth a performance hit.
As a workaround, generate two 16 bit integers and then join
them with (a << 16) | b. This ought to work for practical
purposes; however, the underlying generator may not be
strong enough to make this a theoretically reliable
transform (i.e. it may dramatically shorten the period of
the composite generator).
----------------------------------------------------------------------
Comment By: paul rubin (phr)
Date: 2004-02-21 03:17
Message:
Logged In: YES
user_id=72053
Oops, ignore previous comment, it was added to the wrong
bug. Sorry.
----------------------------------------------------------------------
Comment By: paul rubin (phr)
Date: 2004-02-21 03:16
Message:
Logged In: YES
user_id=72053
It says "; current system time is also used to initialize
the generator when the module is first imported. " That
sugests that the module is passing the current time to the
generator, rather than that the generator is initializing
itself with the current time.
Proposed new wording: ". When a new generator is
instantiated, its inititialization method calls the seed
operation with a parameter of None. The seed method then
uses the current time to initialize the generator as
described above. If you subclass Random, your seed
operation can use some different method to create a default
seed on being initialized with None."
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=901285&group_id=5470
More information about the Python-bugs-list
mailing list