Probability Distribution of Dice

[Unther the unready]

I have been following this and have been writing a program to generate the probability distribution, and have found that the probability of 200 on 20d10 is smaller then the machine error of 110.

Just some food for thought.

And before people ask, I'm using double precision variables in C.

 

[Storminator]

I have been following this and have been writing a program to generate the probability distribution, and have found that the probability of 200 on 20d10 is smaller then the machine error of 110.

Just some food for thought.

And before people ask, I'm using double precision variables in C.

Yeah, with large dice sets the factorial functions start to give you problems.

I didn't check out LL's rewrite of frisbeet's function, but frisbeet's matched up to my "recursive" code for all cases I check (about a dozen or so, with variations in both number and type of dice)

So looks pretty good!

PS

 

[Darius101]

WOW what an interesting thread. Very informative.

Why don't you call Casino Data Systems or IGCA in Nevada to ask them how they generate the random numbers in the computers of their casino games?
Might be interesting to see what they have to say about this subject.
Darius

 

[Drawmack]

WOW what an interesting thread. Very informative.

Why don't you call Casino Data Systems or IGCA in Nevada to ask them how they generate the random numbers in the computers of their casino games?
Might be interesting to see what they have to say about this subject.
Darius

http://www.howstuffworks.com - those machines are not even based on the real rolling of dice at all.

 

[LazarusLong42]

More than one die type...

All right, I've done some figuring, and about the best I can come up with is the following:

where n and d are the number and size of each set of dice; R is the result desired; and N is the total dice. So, for 3d6 + 2d4:

n1 = 3
d1 = 6
n2 = 2
d2 = 4
N = 5

Given this equation and the one above, I think the math-minded people in this thread can easily extrapolate for three or more types of dice. The only problem is how many iterations the algorithm goes for... that is, the definition of m1 and m2 in this equation.

The problem is that there are three criteria:

m1 <= n1;
m2 <= n2;
i*d1 + j*d2 <= R - N

If one defines m1 as in the original equation, one then must find an expression for m2, in terms of n1, n2, d1, d2, R, N, and i. If anyone can find an expression for that, let me know.

 

[tarchon]

Didn't anybody think of searching the net for this? It's a very, very old FAQ, even been answered on this forum several times.
http://www.fantasylibrary.com/lounge/diceprop.htm
is the 2nd one I came up with.

Or, autoconvolve the probability mass function for the single die M times and you're done. I wouldn't waste time resolving it into tangled combinatoric expressions since you 're going to have to iterate whatever you do, and the autoconvolution approach is vastly more efficient if you want to generate the entire table, as well as having the advantage of being far simpler conceptually.

BTW, pseudorandom number generation isn't rocket science either. Every contemporary OS exposes a PRNG in its basic API and it's 100% perfectly adequate for rolling dice. If you're some affected computer science nerd who requires a guaranteed 2^32 cycle PRNG for slaying bugbears and you think the documentation of your favorite API is lying to you, you can even crack open Numerical Recipes and write the 5 lines of code it takes to do it. No need to hire a $100/hr consultant, though I'm up for it if you want to pay me.

 

[Storminator]

Or, autoconvolve the probability mass function for the single die M times and you're done. I wouldn't waste time resolving it into tangled combinatoric expressions since you 're going to have to iterate whatever you do, and the autoconvolution approach is vastly more efficient if you want to generate the entire table, as well as having the advantage of being far simpler conceptually.

Don't you end up with the "recursive" codes generated above in this thread? They have the advantage of allowing different die types, but aren't as mathematically cool to play with.

PS

 

[LazarusLong42]

Or, autoconvolve the probability mass function for the single die M times and you're done. I wouldn't waste time resolving it into tangled combinatoric expressions since you 're going to have to iterate whatever you do, and the autoconvolution approach is vastly more efficient if you want to generate the entire table, as well as having the advantage of being far simpler conceptually.

Well, sure. But that would also be less fun.

BTW, pseudorandom number generation isn't rocket science either. Every contemporary OS exposes a PRNG in its basic API and it's 100% perfectly adequate for rolling dice.

I don't think the point of the OP was creating a program for random number generation. Sometimes, it's just interesting to see what the probability is of, say, rolling 25 or higher on a 5d6 fireball.

 

[Drawmack]

My intent with this program was to be able to write a rndNumber tester. I can find the occurance of a number with the forumla then compare that to what the generator spits out and see how close that is. Many language force the programmer to do hinky things to get anywhere near random numbers when they are generated back to back. For example in perl you either have to wait 1 second between each number or seed your generator between each number. Now that are 24 (6*4) random numbers generated for stats, so that's either 24 calls to the seed function of 24 one second pauses. Just to get something that resembles random numbers.

It took me an entire day to figure that out by digging through their documentation. With a program that could test I could then expound upon that program with a little AI so that it figures out the work around all on its own as well. However I wanted to really understand the forumlas or I wouldn't be able to do that and participating in this work allowed me an in depth understanding of the forumlas I would not have gotten from reading a web page.

However, I thank you for posting that link because now that I have the intimate understanding it will be an invaluale resource.

 

[tarchon]

The advice in the perl manual is for avoiding correlations in the PRNG output (the tendency for an outcome to give information about successive outcomes, essentially). What you're doing just tests the bias of the PRNG. Even the most horribly implemented PRNGs are highly unlikely to have significant bias problems, no matter how frequently you call them. Generic correlations unfortunately can be difficult to characterize, and usually you're best off looking at the requirements of your application and devising a test specifically to determine if the PRNG is adequate for it. No PRNG is perfect (hence the "pseudo") so the question is always "is it good enough?" rather than "is it really random"; the answer to #2 is always "no." The answer to #1 is usually "yes," with the notable exception of some crytpography and Monte Carlo applications. With Monte Carlo, you periodically generate PRNs for 1,000s or 1,000,000s of iterations, so if the PRNG happens to have correlations with even a long period, it can be a problem. You can't really afford 1 second latencies in such cases either, and indeed my biggest beef with system PRNGs used to be their general sloth. Sometimes bitwise correlations get to be a problem too, depending on how you use the PRN.