Thanks,
Alan Beban
I think JB said all the game simulators use the .net standard rand library, which is probably good enough for whatever you are doing as long as its seeded properly.
I recommend the Wizard modify the craps simulator to get the rolls that way. I'm sure we'd all notice the difference!
I heartily support your recommendation. That's where I was headed when I began this thread.
Thanks for responding, and thanks to the other responder as well.
Quote: cowboyThere is a site - random.org - that has random numbers available determined by atmospheric noise. You can grab them one at a time via a web app enquiry or download several thousand at a time the same way, store them up until used, and then go get a bunch more.
I recommend the Wizard modify the craps simulator to get the rolls that way. I'm sure we'd all notice the difference!
WinCraps can easily run roll files created from random.org. I provide a number of free roll files here:
http://www.cloudcitysoftware.com/brfiles.htm
but you can also download your own numbers and create your own roll files. I give complete instructions here:
http://www.cloudcitysoftware.com/wcfaq.htm
Included are also instructions to create roll files from the fourmilab site which uses atomic decay.
Steen
Randomize
roll1 = Int(6 * Rnd +1)
Randomize
roll2 = Int(6 * Rnd +1)
roll = roll1+roll2
Is there something else required for proper seeding?
Thanks again for responding.
Maybe it will be easier when the goal is clear ... Do you need to know the possible outcome of the game, or check the strategy?
With your downloading, do you download a new set each time?
What did you identify as a problem with prng's?
I'm not really savvy enough to characterize it as "a problem with prng's", but the problem I found with Microsoft's randomized Rnd function was the inordinately high rate of success when using algorithmic betting patterns; particularly the absence of long strings of losing bets, a typical nemesis of Martingale-type progressive betting patterns.
Quote: lvnewbieI don't download a new set each time, and probably don't pay enough attention to seeding, although I do often vary the starting point. Also, when the same set of random numbers is used in a different program, is seeding really that important? For example, if a set of random numbers is used once for dice rolls in a program simulating betting on the field in craps, if its next use is in a program simulating betting on the occurrence of double sixes and double aces, so-called high-low bets, does it matter that the starting point in the set of random numbers is the same?
In this case, yes. A "random" set that is heavy in field numbers almost certainly will be light in 2s and 12s. There is a definite correlation between the two outcomes.
Donald Knuth mentions something like 12 tests for "randomness" in volume 2 of The Art of Computer Programming; however, the tests have different definitions of "randomness." For example, one test is, how many times does each result occur; however, if you apply this to 600,000 die rolls that are always in order 1, 2, 3, 4, 5, 6, 1, 2, 3, 4, 5, 6, 1, 2, ..., this "passes the test" as each result comes up 1000 times.
What troubles me more is the notion that a large enough random set will be heavy or light in something. I presume that a five-thousand set of dice rolls will have the number of occurrences of each the 11 possible dice rolls pretty much as predicted by the theory of probability, not be light or heavy in something. What am I missing?
Quote: lvnewbieIs using it before each use of the Rnd function counterproductive or just unnecessary?
It completely invalidates the algorithm. Basically, you are just using the clock -- which is a lousy source of randomness.
Pseudo Random is random enough. Pay attention to the game and not on mathematical purity.
Pseudo Random is random enough. Pay attention to the game and not on mathematical purity.
Quote: lvnewbie... the problem I found with Microsoft's randomized Rnd function was the inordinately high rate of success when using algorithmic betting patterns; particularly the absence of long strings of losing bets
It just seems like if this was the case with prng's that this would be a "known" problem that was often cited.
Quote: lvnewbieA couple of things. I think the first doesn't affect your point, but since 2s and 12s are field numbers, I assume a "random" set that is heavy in field numbers will also be heavy, not light, in 2s and 12s, but that's beside the point of your statement that there's a correlation -- it's just a different correlation.
What troubles me more is the notion that a large enough random set will be heavy or light in something. I presume that a five-thousand set of dice rolls will have the number of occurrences of each the 11 possible dice rolls pretty much as predicted by the theory of probability, not be light or heavy in something. What am I missing?
You're right about the first one; I was thinking of the losing numbers (5, 6, 7, 8) for some reason when I saw "field numbers."
As for the second one, suppose that whoever designed the random number generator decided to choose an integer from 1 to 11 with equal likelihood and add 1 to the result. The number of 2s would then be very close to the number of 7s, so it is heavy in 2s and/or light in 7s (and, in fact, is both; after 7920 rolls ("Why 7920?" It is divisible by both 11 and 36), you would get 720 2s and 720 7s instead of the "expected" 220 2s and 1320 7s).
However, as I said earlier, how close a set is to the expected numbers is not a good test of randomness; if the numbers cycle 2, 3, 4, 5, 6, 7, 3, 4, 5, 6, 7, 8, 4, 5, 6, 7, 8, 9, ..., 7, 8, 9, 10, 11, 12 and start over, then the fraction of times a particular number appears matches the "expected" values, but the sequence is hardly random.
One method of implementing randomness is to have the device generate numbers continuously until an outside event takes place - for example, on a VP machine, when someone presses the "Deal" button. Even with this, the "randomness" of the sequence of numbers is important. Assume a Megabucks slot machine has a 1 in 500 million chance of hitting the jackpot on any particular spin, and it does this by cycling through the numbers from 0 to 499,999,999 at a speed of 500 million per second. There are people who have demonstrated the ability to determine when a cyclic event will happen within 0.1 milliseconds, so allowing for a range of 0.1 milliseconds on either side of the "jackpot number," the player can time it to within a range of 100,000 numbers. Reducing the probability of a jackpot from 1 in 500,000,000 to 1 in 100,000 is a definite advantage play. Of course, that assumes you know exactly when the "jackpot number" last came up on that particular machine.
Quote: lvnewbieDice rolls aren't generated by selecting from integers between 2 and 12; they're generated by selecting from integers between 1 and 6 twice and adding them, just like dice rolls. So the probability of each of the six numbers is equal, but the probability of the sum of the two numbers follows the law of probability--in 36 rolls, one 2, two 3's, three 4's, etc. So with a large enough sample, the set of integers is not heavy or light in any number.
That is true if the RNG draws each number from 1 to 6 with equal probability (or, what is more likely to be the case, it draws a number from 1 to 36, divides it by 6, and rounds up if necessary to get the first digit (i.e. 1-6 is 1, 7-12 is 2, and so on), then takes the remainder from that division and adds 1 to get the second digit). Unless you know exactly how the RNG works, you cannot make that statement with 100% certainty.
Quote: lvnewbieI'm sort of losing focus on what our difference is, but perhaps this will help clarify. I download sets of random numbers from 1 to 6 from Random.Org. I assume they know what they're doing and that I get 5000 random numbers from 1 to 6 per set. Then for each dice roll in my program I make a call to each of two sets and take the sum of those two results.
Assuming random.org knows what it is doing (and I don't see why it wouldn't), you should get 5000 random 2-dice rolls that way. For that matter, if you get one list of 10,000 numbers from 1 to 6, and take the numbers from the list two at a time, the result is also 5000 random 2-dice rolls.
I think our "difference" is, you had more confidence in a "generic" random number generator than I did.
Here's an example - suppose the RNG consists of a Windows .NET program that loops through the numbers 1-6 repeatedly until you press the space bar to stop looping.
The loop that drives the number is this:
int N = 1;
while (IsRunning)
{
N++;
if (N > 6)
{
N = 1;
}
}
where "IsRunning" is a boolean that starts as true, but becomes false when the space bar is pressed.
You would expect N to be "random," but because of the extra step that it has to take when going from 6 to 1, 1 will actually show up more times than the other five numbers.
Quote: QFITIt completely invalidates the algorithm. Basically, you are just using the clock -- which is a lousy source of randomness.
True. "Randomize" seeds the RNG. All numbers produced by RND from then on are pre-defined but unknown, and they are pseudo-random. I used VB RND in a program to analyze betting strategies. The problem with VB RND is that the output eventually will repeat. So starting from the same seed, you might get a good random distribution result with 50,000 trials but a skewed one with 5 million trials.
Depending on what you want to do, you might want to store and re-use the seed, or store and re-use the set of numbers you got from random.org. This could be used FREX to compare two different betting strategies. This way the two strategies would be applied to the same sequence or dice rolls - which would give a better analysis than applying them to two differently seeded sets of dice rolls.
Quote: lvnewbieThanks to cowboy for responding. Pardon me for being thick, but I don't understand "store and reuse the seed" nor "FREX". But thanks.
FREX means "for example."
You would want to re-use the seed if you wanted to test multiple things and wanted to use the same set of numbers in the same order to make it a fair test.
Quote: lvnewbie"Store the seed" and "reuse the seed" are simply going over my head. I really don't understand what seeds are.
A random number generator generates numbers in a particular order. The "seed" is the starting point.
For example, if you want to generate "random" 32-bit (0 to 4,294,967,295) numbers, one way to do it is to start with any number - say, zero - and then generate each number by multiplying the previous number by some number A which is one more than a multiple of 4 (i.e. 1, 5, 9, 13, 17, ...), then adding some odd number B to it, and finally taking the result mod 4,294,967,296. Note that the rules concerning what values of A and B can be used depend on what the range of possible numbers is.
In this case, if A = 5 and B = 11, the first few numbers (remember, the seed is zero) are 0 x 5 + 11 = 11, 11 x 5 + 11 = 66, 66 x 5 + 11 = 341, 341 x 5 + 11 = 1716, and 1716 x 5 + 11 = 8591. (Notice that all of these are multiples of 11; some values A and B are better than others.) Eventually, when you generate 4,294,967,296 numbers, you will notice that every number from 0 to 4,294,967,295 has been generated exactly once - and the last number generated was zero, so the next numbers will be, once again, 11, 66, 341, 1716, and 8591.
If your "seed" was 341 instead of zero, your first two numbers would have been 1716 and 8591.
Quote: lvnewbie"Store the seed" and "reuse the seed" are simply going over my head. I really don't understand what seeds are.
Thank you very much for asking, and TDG for answering. You weren't the only one who needed a simpler explanation. But now I've learned my something for today.
Perhaps "cyclical" isn't the best word. But an example to visualize it:
Apparently there was a small casino or bar that had keno and every night when they closed they'd turn off the keno machine and every morning they'd start it back up. They used the same seed every time it was started up. This resulted in the exact same numbers showing up everyday for the same game rounds. So on round #1, the numbers would always be (an example) 5, 22, 79, 13, etc. and the next day game #1 was 5, 22, 79, 13, etc. Game #2 was always 34, 1, 63, 9, etc. Game #3 was always 48, 80, 26,.... They ended up getting crushed (surprising, huh?).
Quote: RSTLDR version: An RNG produces a cyclical list of numbers. The seed tells you where the starting point is. If you always start off with the same seed, you'll always get the same numbers in the same order starting with the same number.
Perhaps "cyclical" isn't the best word.
If the seed is one of the random numbers, and you can use the seed to duplicate the sequence, then it has to be cyclical.
Let's say that your RNG generates numbers from 1 to 100, in this sequence: 1, 16, 89, 47, 48, 23, 5, 100, 6, 32, (50 or so numbers removed), 66, 1, 25, 38, ...
If the seed is 1, then what is the next number - 16, or 25?
If it can be either one, then you can't use the seed to duplicate the sequence.
One way around this: generate random numbers from 1 to 10,000, then divide each one by 100 and round up to get numbers from 1 to 100.
The sequence can be 125, 1607, 8933, 4701, ..., 6634, 194, 2540, 3840,...; if you divide each by 100 and round up, the sequence is the same as the 1-100 sequence mentioned above.
Seed 125 starts with 1 followed by 16; seed 194 starts with 1 followed by 25.
The command RND yields a fractional number that is in the range of equal to zero up to less than 1. This is why the expression "Int(6 * Rnd +1)" needs to have the one added, so that the possible numbers produced for your program are between 1 and 6.
It does raise for me a number of other questions about seeding, but that's for another thread.
Thanks again for responding.
Quote: FleaStiffA true random generator is something computer scientists and mathematicians will argue about endlessly and make finer and finer cuts of an already split hair. Pseudo Random is random enough. Pay attention to the game and not on mathematical purity.
While arguing over psudo -vs- true randomness is splitting hairs when it comes to high quality cryptographic secure RNG's, I think saying "pseudo-random is enough" is a bit of an overly broad statement, because it can be done poorly, and different algorithms have different levels/sources of entropy. If you search on google, or even these forums, you can find quite a few discussions about standard library RNG's in different programming languages or versions of excel giving bad results for large Monte-Carlo type simulations.
Quote: lvnewbieThanks for responding. Not sure what you mean by "There's no such thing as a true random number generator via software."
Quote: lvnewbieIt does raise for me a number of other questions about seeding, but that's for another thread.
I meant is that any random numbers generated by a computer are technically pseudo-random. Computers aren't physically capable of generating randomness because they are deterministic, meaning any program they execute takes an input and produce a completely predictable output with no variation or error.
Hardware based random number generators, like what random.org seems to be using, attempt to capture some sort of physical noise as a source of entropy. Software based number generators attempt to simulate that chaotic randomness, since they are physically bound to the deterministic nature of computers, thus why they are considered pseudo-random. What these algorithms do is extrapolate a series of pseudo-random values from a fixed input, which is called the seed.
I'm not trying to say that high quality pseudo-random generators aren't a sufficient source of randomness for any particular purpose. We wouldn't have cryptography without them. Seed values can range from things like system time in milliseconds (not a great source of randomness), to a combination of high accuracy system values/counters.
For example, Microsoft's cryptographc secure RNG seeds itself with the following parameters:
- The current process ID
- The current thread ID
- The tick count since boot time
- The current time
- Various high-precision performance counters
- An MD4 hash of the user's environment block, which includes username, computer name, and search path
- High-precision internal CPU counters, such as RDTSC, RDMSR, RDPMC
The best physical analogy of a psuedo-random number generator I can think of is a double pendulum.
Look at this short video:
https://www.youtube.com/watch?v=U39RMUzCjiU
A double pendulum is a chaotic system that is extremely sensitive to an initial state (e.g. the seed state), and the seemingly random motion is very hard to predict/calculate, even though the system still functions within the bounds of physics (e.g. determinism in the case of algorithms).
Quote: QFITQuote: lvnewbieIs using it before each use of the Rnd function counterproductive or just unnecessary?
It completely invalidates the algorithm. Basically, you are just using the clock -- which is a lousy source of randomness.
The reason for this is that the lower effort PRNG's seed themselves with only the system time in milliseconds, and many instructions take less than 1 ms to execute. So if you initialize and seed the generator multiple times in succession, you may very well be seeding it with the same value between generating numbers, and getting a recurring pattern of results.