Different Random Numbers Between Already/Not Yet Compiled Code

[Tim Peters]

[Eric Eide]
> The seed is code is basically: random.seed(1).

"Basically"?  I'd think it is, or it isn't <0.9 wink>.

> I'm not using multiple threads.

That simplifies life, partly because thread execution order is
non-deterministic (the default random instance is shared without locking),
and partly because threading.py itself uses random() (to generate varied
internal wait times).

> The last I'm not sure of, but I would hope that such any such
> modules would at least have predictable behavior between compiled
> and non-compiled code.

You've found correlation but haven't yet demonstrated (at least not via what
you've said) causation.  A module may, e.g., come up with a temp file name
via trying names "at random" until it finds a name that doesn't already
exist.  The odds of that taking more than one try may also be correlated
with your symptoms, and *every* call to random() changes what later calls
will see.

> As an experiment, I downloaded and compiled Python 2.2.  The
> behavior is the same (although I do get a different series of random
> numbers, I assume because the `random.py' library module has changed).

The primary seed function changed, as the old one was incapable of getting
at most of the possible internal states (i.e., it was a poor
implementation).  Do read the new docs for the random module.  One of the
things you'll find is:

    whseed([x])
    This is obsolete, supplied for bit-level compatibility with
    versions of Python prior to 2.1.  See seed for details.  whseed
    does not guarantee that distinct integer arguments yield distinct
    internal states, and can yield no more than about 2**24 distinct
    internal states in all.

> My simulation runs (predictably) differently between compiled and non-
> compiled versions.

Put in "print repr(random())" until you find where they start to diverge?

> It looks like this is interesting enough for me to track down.
> Does anyone have any advice as to how I might go about finding
``interesting  callers'' of the `random' module?

It's Python <wink>.  That is, you've got the source code, and can put in any
instrumentation you want.  You can even replace random.random with your own
wrapper; for example, you could write a wrapper to log the caller and then
delegate to the original random.random.

Without your source code in hand, it's hard to be more specific.  I'd put in
prints (as suggested earlier) to narrow it down.