Re: use of the random library

[Sven N. Thommesen]

Bob,

I hope you don't mind me sending this answer to the 
whole list -- someone else might benefit from the
discussion.

At 11:52 AM 3/27/97 -0800, you wrote:
>Hi Sven!
>
>Since you seem to be the random number library guru I
>thought I'd pose a couple questions to ya. Unfortunately,
>I lost a fair amount of work when changing to the new
>libraries since I didn't realize the new libraries used
>the same default seed...but these are easy questions 
>(I think :-)
>
>1. I assume that once you initialize swarm, you get random
>numbers each time you request a uniformIntRand?
>

Yes. If you read <simtools/global.h> and <simtools/simtools.m>,
you discover that there is one PMMLCG generator defined, as 
well as 3 uniform objects named uniformIntRand, uniformUnsRand
and uniformDblRand. These are globally accessible within any
program you write.

>2. The default seed (simtools.m) is 1234567890L
>What is the L? and any reason why this number?
>

The 'L' designates a value that may be long enough to fill a
long integer. 'LL' would designate a value long enough to fill
a long long integer. In this case (since on my system at least,
a plain integer can hold the value) the L is there just to 
avoid a complaint from the compiler.

The number is entirely arbitrary.

HOWEVER, NOTICE THE FOLLOWING:

a) yes, if you use these builtin objects you get the SAME starting
seed EVERY time. Not useful in your case!

b) all the 3 uniform objects draw their random numbers from the
SAME generator.

>3. You mentioned in the library docs that it is the user
>responsibility to choose a good seed. What defines a
>good seed? 
>

For the current generators, any value that is in the set
of valid output values is fine, i.e. [0, maxValue].

>4. Btw, this is for arborgames. I end up executing
>arborgames 1000 times to study effects of altering
>initial conditions. Each run has an initial random
>distribution of species, so you can imagine my surprise
>to find each of the thousand runs to be identical!
>I didn't check it out very thoroughly since it had
>worked fine under the old version of swarm...oh well!

Yep, in the beta version the default was that you got
a 'random' starting seed depending on the process id
of your program and the system time.  I was not the
one to change that ...

>Anyway, it appears as if I need to set a new seed for
>each run. I suppose if I made them sequential (kind
>of a seed++ thing) that that would induce a correlation.
>Know of a way to do this? The positive side here is
>that by knowing my seeds I can reproduce any unusual
>run that might occur :-) or should I use the canonical
>[grin] from glen.
>

You are hitting a sore point here. With the current generators,
yes, you need to start each of your 1000 runs with a different
seed, and those 1000 seeds should be spread roughly evenly among
the possible starting seeds. This will ensure some degree of
independence between runs.

However, note that if you do 1000 runs and each run requires
10e8 random variates, the total number of variates required for
your experiment (10e11) exceeds the period of every generator
but SWB.

What would be nice would be a generator where we could extract
non-overlapping sequences of random numbers long enough for any
single run you'd want to make.

I am in the process of implementing and testing such a generator.

In the mean time, SWB is the best we've got. Unfortunately, there
is no way to 'jump ahead' with this generator to guarantee us
non-overlapping sequences. So the best that can be done is to 
give it those evenly spaced starting seeds ... (And yes, you 
definitely want to save the value of the starting seeds with 
the rest of your results, so that you can re-create any run later.)

>Thanks,
>Bob Bell
>Dept. of Geography
>UCLA
>

If you want to make yourself independent of the 'automagic'
generator provided, here's my own code:

a) I have a file named "myRandom.h" that has these definitions:

---------------------------------------------------------------
// "myRandom.h"

#import <random/PMMLCGgen.h>
#import
<random/UniformInteger.h>
#import <random/UniformUnsigned.h>
#import
<random/UniformDouble.h>

// global random number generators
(defaults)

extern id <PMMLCG1>          randomGenerator1;
extern id
<UniformInteger>   uniformRandomInt;

extern id <PMMLCG2>
randomGenerator2;
extern id <UniformUnsigned>  uniformRandomUns;

extern id
<PMMLCG3>          randomGenerator3;
extern id <UniformDouble>
uniformRandomDbl;
----------------------------------------------------------
-----

You'll want to #import this file in any .m file that actually
uses these objects. The names chosen do not conflict with those
of the automagically provided objects.


b) Then, in my modelSwarm.m (!!) I have these definitions:

----------------------------------------------------------
// Definitions for random generators:
#import "myRandom.h"

id <PMMLCG1>
     randomGenerator1;
id <PMMLCG2>         randomGenerator2;
id <PMMLCG3>
       randomGenerator3;

id <UniformInteger>  uniformRandomInt;
id
<UniformUnsigned> uniformRandomUns;
id <UniformDouble>   uniformRandomDbl;
---------------------------------------------------------------


c) Finally, in my modelSwarm.m, in method buildObjects, I have:
---------------------------------------------------------------
   randomGenerator1 = [ PMMLCG1 create: globalZone
                        setStateFromSeed:
randomSeed1 ];

   randomGenerator2 = [ PMMLCG2 create: globalZone

setStateFromSeed: randomSeed2 ];

   randomGenerator3 = [ PMMLCG3 create:
globalZone
                        setStateFromSeed: randomSeed3 ];

   uniformRandomInt = [
UniformInteger create: globalZone
                        setGenerator: randomGenerator1 ];


uniformRandomUns = [ UniformUnsigned create: globalZone
                        setGenerator:
randomGenerator2 ];

   uniformRandomDbl = [ UniformDouble create:
globalZone
                        setGenerator: randomGenerator3 ];
---------------------------------------------------------------

Note #1: this is how you specify the seed at creation.

Note #2: as you can see, in my case I connect the 3
distribution objects to separate generators;

Note #3: I'm using PMMLCG here; since you need more
numbers than PMMLCG can provide, you might want to use
the SWB generators instead.


The current set of generators is not ideal for situations
where you need large sets of numbers; I'm working on
finding better solutions ...

In the mean time,
the above plus a reading of the release documentation
(you DID read that, yes?)
should afford you some help.

Ciao,
Sven