Re: Random Seed question

[Sven N. Thommesen]

At 10:31 PM 1/28/2000 -0500, Olga Gilmore wrote:
> Could someone please advise me what numbers
> are the best to use in the
> PMMLCG1genImpl class constructor? Are prime numbers preferred? We are
> trying
> to tackle this issue to pick a baseline for our experiments.
> Your insight in this area will be appreciated.


Olga, I'll answer your question, by way of a little tour of the Swarm
random generators. 

(a) In order to simplify life for the Swarm user, the generators all
accept a single seed value in the form of an unsigned integer in the
range [1, 2^32-1]. The value 0 is not allowed, since some generators (the
PMMLCG family is an example) would give degenerate output with such a
seed. Some of the implemented generators cannot use a seed value that
goes all the way up to 2^32-1, and in this case I just use the given seed
value modulo the generator's actual max value. 

It is true that some older generators (as discussed by Knuth for example)
cannot use certain seed values, but none of the generators recommended
for serious use in Swarm have this problem.

So the answer to your specific question about PMMLCG1 is that no
particular seed value is better than any other. But be aware that this
particular generator has a small state (one integer) and a
correspondingly small period (2^31), so this generator should NOT be used
for serious simulations! (You could easily "wrap around" and
begin repeating the generator's output.)

(b) You may object that java doesn't provide unsigned integers, only
signed ones. I am assured by Marcus that signed integers in java are
mapped in an obvious one-to-one fashion to unsigned integers in objC. So
in java you should be able to use any non-zero integer value as a
seed.

Similarly, the generators all provide unsigned integer output in objC; on
their way to java these integers are mapped in an obvious way: values
> 2^31 in objC become negative numbers in java.

(c) Most of the generators in Swarm have a larger state than a single
integer, in order to get a longer period. (For example, the default
generator MT19937 has a state of 624 integers to get a period of
2^19937.) For such generators, you have two choices:

c.1: create the generator using a single seed, as described above. In
this case, I use the given seed to start up an inline PMMLCG generator,
and this generator is used to generate the required number of integers to
fill the state. This procedure should in general be quite
acceptable.

However, as noted by Glen, using a 32bit seed cannot give us more than
2^32 different starting configurations for the state, and for MT19937
that's quite a small set compared to the 2^19937 possible configurations
for the state. There is no guarantee that the procedure used covers the
set of possible configurations in an "even" manner. If this
worries you, there is

c.2: you have the ability to furnish all the bits required to fill the
state yourself (i.e. 624 integers in the case of MT19937.) If you have a
good source of truly random numbers, this would be doable. Just don't
forget that you'll need to record all the bits provided to the generator
in this manner if you should want to replicate your run later! Most users
will find it easier to provide, and record, a single integer.

[Unfortunately, this part of the API has not been extended to the java
side in 2.0.1.]

d) If you use the default generator and don't specify anything on the
command line, the default generator will be created with the SAME default
starting seed EVERY TIME. 

e) If you say --varySeed on the command line, the default generator will
be initialized with a seed that depends on the time and the process id,
which should be different from run to run, as well as different for two
simulations running concurrently, even if they started at the same time.
Don't forget to record the starting seed in case you should want to
replicate a run later. (Just ask the generator what seed it was started
with.)

f) If you need to run a large set of simulations (replications), you can
start each run using --varySeed to get different seeds; or if you want to
manage things yourself you could use some external RNG or (better) some
source of actual randomness to have a set of "random" seeds
handy. [Thanks to Glen for the url to random.org!] However, in light of
the way seeds are translated into states, I don't see why a number of
runs cannot just be given successive integers as starting seeds, as
suggested by Rick.

g) Drone takes a single starting seed, and furnishes each run of the
simulation with a seed produced by an RNG internal to Drone.

h) For large simulations, one can either use a single generator of
sufficient period (such as the default MT19937 generator) and let all
objects/agents draw random numbers from it; or, one can create a large
number of generators, perhaps to the point of letting each
"user" of random numbers have its own generator. BE AWARE that
in the latter case you need to manage your starting seeds explicitly, to
avoid having generators which start at the same point and thus generate
perfectly correlated sequences. Such a situation would result, for
example, if all the generators were created with the default seed and you
didn't say --varySeed.

There is a lot of documentation for the random generators and the
distributions, but it is sort of hidden away. Do follow *all* the links
to the "Random Appendix" in the reference manual -- this
"appendix" has several different sections to it!

Happy modelling,

Sven Thommesen



                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to

with "help" in the body of the message.