Kenneth <kdw### [at] earthlinknet> wrote:
> Let's see if I can phrase this correctly:  Say you choose SEED(432) to
> initialize your first random number process. Then the first "random" number
> that RAND chooses from that will be, let us say, .36547 (not really, that's
> just a guess.) And the next "random" number that RAND chooses will be, let
> us say, .85645.  Fine and dandy, so far. NOW, if you then, without
> thinking, choose to initialize a new SEED as SEED (433) -- i.e., only one
> integer number away from your first SEED value-- then the very first
> "random" number that this new SEED's RAND function will choose will be, lo
> and behold, .85645---the very same "random" number that the FIRST SEED's
> 2nd RAND  function returned!  Am I making sense?

  It's logical to come to that conclusion from my explanation, but it
doesn't work like that.
  You see, I said "you can think of it as an index", but it's not a
linear index. The seed value is closely related to the random number
generation itself, which means that the relation between a seed value
and the value returned by rand() is pseudorandom as well.

  Ok, I'm not even sure myself that that explanation was understanble (or
even correct, for that matter).
  What I mean is that the order in which rand() pops numbers from the list
is not the same order as seed() "indexes" that list. The "index" jumps
pseudorandomly over the "list" of numbers. This means that if you use
seed(100), pop a number with rand() and then another, that next number
might well correspond to something like what seed(5033921) will make
rand() to return at first.

  The seed value (which is a 32-bit integer) jumps pseudorandomly over
its entire value space (ie. between 0 and 2^32-1) and the value returned
by rand() is simply calculated from this seed value.
  The formula which modifies the seed value is just so incredibly ingenuous
that it will really go through all 2^32 possible values in a pseudorandom
order before starting over.

> If my thinking is correct, this is wholly different behavior than if SEED
> created completely *new and different* random number streams for each and
> every number that was placed into it.

  From the point of view of the user it is almost as good as if seed()
created completely new random streams for every different value of seed()
because there's very seldom any overlapping. In some rare cases you might
encounter that one rand() starts repeating the same values as another rand()
using a different seed, but that happens very rarely.
  After all, you have 2^32 possible start points to start from (and it's
very hard to find start points which are close together).

-- 
                                                          - Warp

Post a reply to this message