Random algorithm

[Richard Gaskin]

Jan Schenkel wrote:

 > --- Richard Gaskin <ambassador at fourthworld.com> wrote:
 >> >>    set the randomSeed to random(4570422)
 >>
 >> It would seem that resetting the randomSeed each
 >> time you use the random function would only have
 >> a 1-in-4,570,422 chance of getting the same seed
 >> as the previous run, no?
 >
 > If you set off with the same randomSeed, the random
 > function will return the same result; ergo you're
 > resetting the randomSeed with the same number, which
 > means the next number coming out of the random
 > function would also be the same.

True, and I've used this to my advantage in some modest encryption 
algorithms to arrive at non-obvious but reproducible patterns.

To make a simplistic example, we could assume this:

  set the randomSeed to 10

...will produce this result for calling random(10) 3 times:

   5
   8
   2

If you then set the randomSeed to 10 again and call random(10) another 
three times, you'll get the same set of results (5,8,2).

This is useful if you want to reproduce a given pattern, but of course 
less useful to simulate the ideal of true randomness.

To closer approximate that ideal (and like all ideals in an imperfect 
world, it can only be an approximation) we can change the randomSeed to 
a different number each time we want to use it.

But as you noted, since random() will deliver the same sequence of 
results for a given seed, using it to set the randomSeed will provide 
nothing more than a level of misdirection for what is ultimately still a 
fixed pattern of results.

So we might try something like this:

   set the randomSeed to 10
   put random(10) into x -- x is now 5
   set the randomSeed to x
   put random(10) into y

...and no matter how many times we run this, y will always be the same 
number.

But this is different from my original suggestion.  This one sets the 
randomSeed to a fixed number, while my original suggestion changes it on 
the fly:

   set the randomSeed to random(tSomeLargeNumber)

Even then we might get the same randomSeed in every session if Rev 
started out each time using the same number.

Fortunately, it doesn't.  Rev sets the randomSeed to some non-fixed 
number (a truncated portion of the milliseconds?) each time it starts.

This implies that each session starts with a unique seed, so each 
sequence derived from it will be similarly unique.

Further permutations within that session will also be reasonably unique 
as long as we continue to avoid setting the randomSeed to a fixed number.

So unless I'm missing something obvious (and it certainly wouldn't be 
the first time), beginning with a fresh seed as Rev does and then 
resetting it each time during the session seems a fair way to avoid 
discernible reproducible patterns for most applications.


Of course, randomness being what it is, we may just as likely find a 
pattern in a truly random series as in a pseudo-random one.

In a universe replete with synchronicity while seemingly devoid of true 
randomness, the pursuit of ideal randomness is the domain of the 
philosopher and perhaps a few pernickety referees of academic journals. :)

For us mere applications programmers, we're faced with a simpler, 
arguably more pragmatic question:  What are the implications of 
psuedo-randomness for our work?

For my own modest needs, Malte summed it up well:

   I really like the way the random algorithm the way it is
   implemented in Revolution, as a seeded algorithm can be
   used in many ways in games. It prevents the ability to
   cheat with undo systems in casual games, or even lets you
   set up whole galaxies without stuffing memory.

-- 
  Richard Gaskin
  Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com