1. Separate threads of random numbers
Hello,
I need to have separate "threads" of random numbers available in
parallel. It is very important that one thread doesn't affect
(unrandomize) the other AND that any given thread will generate the same
series of numbers starting with a given seed.
The first requirement can be achieved easily enough by (when switching
threads) generating a random number in the current thread, saving that
number to be used to re-initialize the first thread later, then using a
saved seed for the second thread to initialize that, etc. etc. This way
the threads are effectively separate (in terms of maintaining
randomness.)
The problem is there is no point to doing that unless you can satisfy
the second requirement, which you can't using that method because you
never know when the other thread is going to "interrupt" the flow of the
first thread and cause it to go off in a different direction.
I need to be able to periodically re-start one thread with the same seed
and get the same series of numbers, while the other thread goes on its
merry way without being affected (and without affecting the first
thread).
Is there any way to do this without completely separate generators?
(That is reasonably efficient -- i.e. not re-generating all the numbers
up to that point.) As far as I know there is no (predictable) way to
seed the generator so that it will "take up where it left off".
I'm actually doing this now with two threads/two generators -- the
built-in one & the Mersenne Twister one in the library. But now I need
to add a third thread...
2. Re: Separate threads of random numbers
On Sun, 7 Apr 2002 14:10:25 +0000, Andy Serpa
<renegade at earthling.net> wrote:
How about doing this:
init():
set_rand(12345)
seed[1]=rand(1073741823) -- use max range for thread seeds
seed[2]=rand(1073741823)
seed[3]=rand(1073741823)
&
function get_next_rand(integer thread, integer limit)
integer result
set_rand(seed[thread])
result=rand(limit)
seed[thread]=rand(1073741823)
return result
Pete
3. Re: Separate threads of random numbers
Matt Lewis writes:
> Actually, [individual] roulette wheels aren't very random. They tend to
> have very distinct statistical patterns.
As a kid one summer, I learned a bit about probability,
and decided to profit from it. I pulled out a cheap plastic
roulette wheel and invited some other kids to bet
on it using pennies and nickels. I of course would be the "house",
knowing that the house owns "0" and "00" and should make
a profit in the long run, whether you bet black vs red, or
individual numbers etc.
I made a few bucks as expected from most of the kids,
but one kid, who kept betting on his "lucky number", was
consistently winning more money than he was losing.
He was a serious threat to my profitability, but at first
I just dismissed it, assuming that probability would
win out in the long run. After a while though, it was driving me
nuts, so I took the wheel home and ran hundreds of spins,
recording which number came up each time.
When I found that his "lucky" number was one of the two or three
best numbers, I eventually took a look at the
wheel. What I found was a cheap plastic wheel with a strip
of paper around the outside. The paper had the numbers
printed on it, and right near his "lucky" number the paper
had separated from the glue and was sticking up a bit,
making it much more likely for the ball to stop there
and fall in the pocket. The other good numbers were
right next to his number. I don't think he was aware of
why his number was winning, but I lost interest
in roulette at that point.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
4. Re: Separate threads of random numbers
Or use some portions of the output of a webcam pointed at a busy street, or,
of course, at a lava light :)
Dan Moyer
----- Original Message -----
From: "Kat" <gertie at PELL.NET>
To: "EUforum" <EUforum at topica.com>
Subject: RE: Separate threads of random numbers
>
> On 10 Apr 2002, at 16:57, Rod Jackson wrote:
>
> >
> > Andy Serpa wrote:
> > >
> > > > Looks good, but will this avoid any algorithmic pitfalls? I.e.,
> > > > one thread in 100 finds a quirk in the psuedorandom algorithm
> > > > and continually brings up the same number over and over? Stuff
> > > > like that can be a headache....
> > > >
> > >
> > > That's the sort of thing I need to avoid, and is the reason for
> > > separating the threads. Under the proposed system, how would the same
> > > number keep repeated itself? Could you detail the possible "chain"
that
> > >
> > > worries you?
> >
> > Well, just off the top of my head...
> >
> > Thread #5 might have a unique, "problematic" seed value to start
> > out. This seed value will generate a random number like usual, and
> > of course the next number could then be used as the new seed. This
> > new seed will then generate a new random number, but then the next
> > number is the same as the ORIGINAL seed value. That number then
> > replaces the new seed, so in essence the seed just keeps switching
> > between two numbers.
>
> <snip>
>
> I have often wondered why people don't look to nature for random numbers.
> There, i was just wondering it again! Like, take a random weather reading
> from a list of locations around the world, perform random math on it with
a
> reading from another location, or a random number of random readings. Or
> against the 3D location in the sky of a random planetary body. Even if one
> cannot do this in real time, one can bank the readings for use as needed,
or
> as seed values in conventional random number generator. This would give
> you values no one has control over, and are unlikely to be repeatable.
Scope
> might be a problem, or significant digits, so loop the random math
operations
> untill you get the digits (altho this will put you somewhat at the mercy
of the
> math chip peculiarities).
>
> Kat
>
