1. Separate threads of random numbers
- Posted by Andy Serpa <renegade at earthling.net> Apr 07, 2002
- 433 views
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
- Posted by petelomax at blueyonder.co.uk Apr 07, 2002
- 421 views
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
- Posted by Robert Craig <rds at RapidEuphoria.com> Apr 10, 2002
- 425 views
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
- Posted by Dan Moyer <DANIELMOYER at prodigy.net> Apr 11, 2002
- 416 views
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 >