In article <fl8ucq$28hr$1@ihnp4.ucsd.edu>,
Patricia Shanahan <pats@acm.org> wrote:
Why would it matter how many times the program is run? I don't see
anything (although I didn't do a deep search) in the documentation of
Math.random() that says the first value returned across different runs
of the programs must satisfy any particular distribution requirements.
The Math.random() documentation says "When this method is first called,
it creates a single new pseudorandom-number generator, exactly as if by
the expression
new java.util.Random
This new pseudorandom-number generator is used thereafter for all calls
to this method and is used nowhere else."
The java.util.Random documentation says that the parameterless
constructor "sets the seed of the random number generator to a value
very likely to be distinct from any other invocation of this
constructor." The algorithms for generating the streams of numbers from
the seed are fully documented.
I don't see how a compile-time selection could conform to that contract,
because it would act as though seed were the same for every invokation
of the java.util.Random constructor.
Is that talking about different invocations within a program, or across
all programs? I see they've changed the documentation since 1.4. In
1.4, it used the millisecond time as the seed, so two separate programs
starting at the same time could get the same seed. The later
documentation just says very likely to be distinct and doesn't give
details.
Given that it is a 48 bit seed, if they do it at random, then about
every 16 million times, there would be a duplicate seed (birthday
paradox argument on 2^48). If they initialize partially with random and
partly with something derived from time, collisions from programs
launched apart in time would be less likely, but among all being
launched near in time, they would be more likely.
System.nanoTime(). I think it would be practically impossible to get
unlikely", but not something happening every time. Indeed, the use of