mark at microenh.com
Mon Mar 2 18:36:27 CET 2009
On Mon, 2009-03-02 at 12:13 -0500, William McVey wrote:
> On Mon, 2009-03-02 at 09:55 -0500, Mark Erbaugh wrote:
> > I've written a Python program that generates tests and answer keys from
> > a pool of questions. It uses random.seed with a user entered value so
> > that the user can regenerate the same test sequence if needed.
> > This morning, I discovered that the same seed doesn't produce the same
> > random values on 32-bit and 64-bit systems.
> This doesn't seem to be an issue for the systems I'm on:
> > I think the problem is that hash(<str>) generates different values on
> > the 32 and 64 bit systems. I found that by using
Thanks for checking. The reason you got the same results is that
random.seed doesn't use hash if the seed is an int or long. In my case,
I was using strings where it does use hash.
> This is where you problem is. hash() is not guaranteed to be consistent
> across hosts. I don't think it's even guaranteed to be consistent across
> invocations on the same host. The fact that it is stable across hosts on
> the same platform is an implementation artifact which shouldn't be
> depended upon. You can check out
> http://docs.python.org/reference/datamodel.html#object.__hash__ for more
> info on why hash() returns different values on 32bit system and 64 bit
> systems. I would highly suggest using one the hash functions in the
> hashlib standard module, which are based on defined standards which are
> guaranteed to yield a stable value across invocations, hosts, platforms,
> python implementations. Alternatively, if you demand high performance
> but not an extremely large set of possible seed values, you could look
> into the binascii module which have several routines to map a string
> into integer in a consistent manner (e.g. binascii.crc32).
> > I can get the same results. Is there a better way?
> Yes. Use hashlib.
> > Is my way "safe" and repeatable?
> Nope. You have a workaround for an implementation artifact; however,
> Jython, IronPython, or PyPy may choose to calculate hash() values of
> strings differently than CPython. Even differing versions of CPython on
> the same platform may introduce incompatible hash() values as well.
Thanks for the information.
More information about the CentralOH