1. RE: Separate threads of random numbers
Thanks, Pete.
Sometimes I am so stupid. The more obvious something is the less chance
I have to notice it. I wrote something almost identical except I didn't
set the seed EVERY time I got a value as I should, but only when I was
switching threads. When I realized that didn't work, my brain
apparently threw out the whole concept...
petelomax at blueyonder.co.uk wrote:
> 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
>
>
2. RE: Separate threads of random numbers
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....
Could you not rewrite the M. Twister to use multiple independent
"sets" of random numbers? For example, instead of simply one
sequence holding the state of the twister, have several that hold
the state of several twisters. I think it would do the trick, and
wouldn't be a lot of work... I'd try it myself, but don't think
I'll have the time. Then again, this may suit your needs anyway.
Rod
Andy Serpa wrote:
> Thanks, Pete.
>
> Sometimes I am so stupid. The more obvious something is the less chance
>
> I have to notice it. I wrote something almost identical except I didn't
> set the seed EVERY time I got a value as I should, but only when I was
> switching threads. When I realized that didn't work, my brain
> apparently threw out the whole concept...
>
>
> petelomax at blueyonder.co.uk wrote:
> > 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
3. RE: Separate threads of random numbers
> 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?
> Could you not rewrite the M. Twister to use multiple independent
> "sets" of random numbers? For example, instead of simply one
> sequence holding the state of the twister, have several that hold
> the state of several twisters. I think it would do the trick, and
> wouldn't be a lot of work... I'd try it myself, but don't think
> I'll have the time. Then again, this may suit your needs anyway.
>
Yeah, my lazy solution would be to just rename the Twister routines and
include it twice or three times and start with different seeds. But
using the Twister at all is a lot slower than using the built-in, so I'd
like to avoid it. Having a super-great generator is not particularly
important -- I just need to make sure I don't get stuck in a short-term
repeating oscillation in thread 2 or 3 when I reset the seed over & over
to the same value in thread 1, which I do want to repeat.
4. RE: Separate threads of random numbers
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. You ask for 100 random numbers in a row from
the thread, and you get a repeating pattern of two integers. Or it
might take three, or more steps for the repetition to occur...
Granted, this might not be feasible; the likelihood of recurring
numbers may be no more than that of using the pseudorandom
generator *without* seeding. It was something that popped up in
my head.
Rod
5. 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
6. RE: Separate threads of random 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).
>
Isn't that how they first did it -- roulette wheels and such? The
results didn't LOOK "random enough" so they invented these algorithms...
7. RE: Separate threads of random numbers
> -----Original Message-----
> From: Andy Serpa [mailto:renegade at earthling.net]
> Isn't that how they first did it -- roulette wheels and such? The
> results didn't LOOK "random enough" so they invented these
> algorithms...
Actually, [individual] roulette wheels aren't very random. They tend to
have very distinct statistical patterns. I believe that a group from some
university figured out how to measure and calculate these patterns using
computers worn in their shoes, and beat the pants off the casinos. That's
one reason why they regularly change the wheels these days.
However, I think that now you start to get into the philosophy of random
numbers. IMHO, it really depends on what you're doing. If you need totally
secret communications, then a one-time cipher based on meteorological data
might be just the ticket. If you're generating random outcomes for a GA
process, then a decent PRNG is probably good enough. You need to look at
the effects and likelihood of prediction and repeatability/patterns.
But remember: 1,2,3,4,5 is as likely as 12312,543,23423,245,8907 in a truly
random stream. :)
Matt Lewis
8. RE: Separate threads of random numbers
> Actually, [individual] roulette wheels aren't very random. They tend to
> have very distinct statistical patterns. I believe that a group from
> some
> university figured out how to measure and calculate these patterns using
> computers worn in their shoes, and beat the pants off the casinos.
> That's
> one reason why they regularly change the wheels these days.
>
The computers in the shoes guys didn't use statistics -- they used
physics. They would tap a button with their toe as the ball passed by a
certain point on the wheel. They'd let it go around a couple more times
and tap again when it hit that point. The computer would figure out the
deceleration rate & predict which quadrant the of the wheel the ball
would land in. The computer would vibrate a signal to the wearer, who
would signal a second person who'd quickly throw down bets on the
numbers in that quadrant.
And although they had a few successful days, they didn't beat the pants
off anyone. The computers were unstable, kept breaking due to sweat,
burning their feet, etc.
It is detailed in a book called the "The Eudaemonic Pie" by Thomas
Bass...
9. RE: Separate threads of random numbers
Kat wrote:
<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).
This seems like a good idea, and for many people it works well.
But it has problems, and so care must be taken for 'true' randomness.
For example, in any natural set of numbers, if you pull the first
digit, "1" will occur more often than any other number. Similarly,
if you just look through a list of small natural numbers, 1 through
3 tend to be more common. I think there are other peculiarities
among natural numbers as well; for 'high-quality' randomness, one
might want to note and avoid these pitfalls.
Rod
