Probability Distribution of Dice

nsruf said:


Good, so I won't have to update my script (which is the same as yours anyway, except for assuming equal dice). Now we only need someone to solve the theoretical problem and give an explicit formula for the number of combinations...

Yeah. My mod to frisbeet's script didn't work either. There's something about the center region that's a bear to calculate. And unfortunately, those formulae involve factorials, which start to get out of hand quickly. Matlab warns against using factorial with numbers over 21, which severely limits its usefulness here.

We could simplify the formula by hand first tho... hmmmm.

PS
 

log in or register to remove this ad


Storminator said:
Yeah. My mod to frisbeet's script didn't work either. There's something about the center region that's a bear to calculate. And unfortunately, those formulae involve factorials, which start to get out of hand quickly. Matlab warns against using factorial with numbers over 21, which severely limits its usefulness here.

We could simplify the formula by hand first tho... hmmmm.

There is always the learning formula where you remember previously calculated factorials and then begin from the highest one to work up. Then you populate it up to like 1000 and it works very nicely.
 

Sorry.

space isn't a function, it's an array of answers. I build up the solutions one die at a time, and store the previous results. So the first row of space contains

1 1 1 1 0 0 0 ....

because there is exactly one way to roll a 1, one way to roll a 2, etc. My example used a d4 to start so that's what I've shown here. The second row of space gives the combos of a d4 and a d6 (again, following the example. It'll do whatever dice you tell it). So the second row has

0 1 2 3 4 4 4 3 2 1 0 ...

because there are zero ways of rolling a 1, 1 way of rolling a 2, 2 ways of rollinga three...

Since I just count the way it avoids the duplication problem.

PS

edit: removed nonsense :)
 
Last edited:

Drawmack said:


There is always the learning formula where you remember previously calculated factorials and then begin from the highest one to work up. Then you populate it up to like 1000 and it works very nicely.

The problem is that floating point numbers lose precision when you divide enormous numbers by enormous numbers. Once in college I wrote a program that did long division (just like you do it by hand...) to avoid this issue, but I'm never doing that again. :)

My thought was that you could figure out which terms in numerator and denominator will cancel, and then multipy out only the terms you need. More work for the man, less for the machine.

PS
 

I was attempting to convert the non-recursive formula to php. I got lost by this line:
space(k,q)=sum(space(k-1,minnum:q-1)); % sums up a number of entries from the previous row

could someone who knows this language put that into standard arithmetic or explain it to me please?
 

I have 2/3 of a formula. I got the symertic part correct but the creamy filling is still wrong:
R = number of combinations that yield a given result.
oc = outcome
n = number of dice
s = sides
M = mean roll

M = (n(s+1))/2

R = (M-|oc-M|-1)!/(((M-|oc-M|-1)-(n-1))!(n-1)!)

this fails at oc = s+n, and its symetric counterpart.

See attached spreadsheet
 

Attachments


Drawmack said:
space(k,q)=sum(space(k-1,minnum:q-1));

space(k,q) is the q-th entry in the k-th row of matrix (2-dim array) "space"

its value is calculated as the sum over the entries ranging from "minnum" to q-1 in the (k-1)st row of "space"

(matlab is very efficient for vector/matrix calculations)
 

Well, I'm not good at math terminology. So I'll create my own, replete with IF statements. I'm not sure but what this replicates Kugar's work, except that it works for all outcomes(for identical dice).

Again,

oc = outcome
n = number of identical dice
s = sides of die

Also,

COMB(a,b) = a!/[b!(a-b)!]


SUM(i=a,b) {term} = sum all terms starting with the "ath" and ending with the "bth", where i = index)

and

IF(condition,if true do this,if false do this) = you get the picture

Then the # ways

= COMB(oc-1,n-1) + SUM(i=1,n-1) {(-1)^i * IF[oc<(i*s+n),0,COMB(n,i)*COMB(oc-i*s-1,n-1)]}

ta dah. I think this is right but often I'm not.

EDIT:
Sure enough, I switched to variables. #(*&#*(@$^!@

Before,

the # ways

= COMB(oc-1,n-1) + SUM(i=1,n-1) {(-1)^i * IF[oc<(i*n+s),0,COMB(n,i)*COMB(oc-i*s-1,n-1)]}

After,

...IF[oc<(i*s+n),...
 
Last edited:

An example, because I don't want this thread to die today.

If

# ways

= COMB(oc-1,n-1) + SUM(i=1,n-1) {(-1)^i * IF[oc<(i*s+n),0,COMB(n,i)*COMB(oc-i*s-1,n-1)]}

Then

for 4d6,

# ways of getting a 17 =

= COMB(16,3) - COMB(4,1)*COMB(10,3) + COMB(4,2)*COMB(4,3) - 0


= 16!/(13!*3!) - 4!/(3!*1!)*10!/(7!*3!) + 4!/(2!*2!)*4!/(1!*3!)

= 16*15*14/6 - 4*10*9*8/6 + (4*3/2)*4

= 560 - 480 + 24

= 104

Sure enough, there are 104 ways to sum to 17 with 4 six-sided dice. Here's how I counted it. Determine all possible outcomes, then how many ways there are of rolling each outcome. So that's:

oc (each digit is a single die result)__# ways

6641___12
6632___12
6551___12
6542___24
6533___12
6443___12
5552___4
5543___12
5444___4

sum of # ways: 104. Not a proof but good enough for me.


EDIT:
changed
= COMB(17,3) - COMB(4,1)*COMB(10,3) + COMB(4,2)*COMB(4,3) - 0

to

= COMB(16,3) - COMB(4,1)*COMB(10,3) + COMB(4,2)*COMB(4,3) - 0
 
Last edited:

Remove ads

Top