33 Posts
BoardGameGeek» Forums » Board Game Design » Design Queries and Problems
Subject: Dice probability problem.
Your Tags:  Add tags 
Popular Tags:  View All]  [

Antistone wrote:I didn't say it was impractical, I said it was not easier than the obvious Monte Carlo approach. Timothy seemed to be implying that the difficulty was proportional to the number of die rolls that would be made when running the program, which from the programmer's perspective is not even close to true.
For the record, anydice calculates exact results, so I actually posted an implementation of this before it even became a discussion point.
Computation power necessary is proportional to the number of rolls made. That was the angle I was coming at. But if you're programming, then I assume you're trying to avoid figuring out the problem, but if you use a Monte Carlo approach you have to be careful about how many trials you do, and there's always a chance it'll just give you a wrong answer.
But on programming effort, I don't see how generating random rolls is any different than looping over all results for each die.
 [+] Dice rolls
 I really did not think "doing the same thing a million times is simpler than doing a million slightly different things" was going to be such a controversial sentiment!
 [+] Dice rolls

Antistone wrote:I really did not think "doing the same thing a million times is simpler than doing a million slightly different things" was going to be such a controversial sentiment!
Haha. Yeah, I was thinking that we're just coming from very different inclinations in approaching such problems.
 [+] Dice rolls

Antistone wrote:I really did not think "doing the same thing a million times is simpler than doing a million slightly different things" was going to be such a controversial sentiment!
I totally agree with the bolded statement. I just don't think it necessarily applies here. Once we've generated our samples, we're both going to do the same processing on the data. My Python code isn't going to do slightly different things. And I'd argue that it is, at worst, slightly less simple to code than a pair of nested for loops calling a random number generator.
Granted, not everybody codes in Python, and not all languages have Python's list comprehension. So, depending on what tools you're using, the method I used may be more complex.
I generally try to compute probabilities by hand. If the problem is too complex, but the number of outcomes is reasonable (say fewer than 10^10), I'll write code to compute the exact (or at least to some reasonable number of decimal places) value. Otherwise, I'll generate random samples.
 [+] Dice rolls

mrickert wrote:My Python code isn't going to do slightly different things. And I'd argue that it is, at worst, slightly less simple to code than a pair of nested for loops calling a random number generator.I don't think your solution is the first thing most people would come up with, regardless of language. I think most people would start with the idea of having a number of nested loops equal to the number of dice, and then possibly try to generalize that into a recursive algorithm that can handle an arbitrary number of dice.
Your solution is a fairly clever optimization based on the insight that you can collapse all of that nested logic into a flat list if you can write an algorithm that efficiently converts the number N into the Nth possible die roll. If you gave this problem to a class of midlevel CS students, I suspect relatively few of them would come to that insight on their own.
Even once you have that insight, writing that conversion algorithm requires a nontrivial level of mathematical expertise (converting a number into an arbitrary base isn't super complex, but it's a bit esoteric), and could become dramatically harder if you introduced some more complex rolling rules. For instance, something like "roll dice one at a time until any two of them match, then take the sum of all your dice so far" requires only minor modifications to what I claim is the "obvious" algorithm, but it makes your approach hard enough that I suspect most people would switch approaches even if they were already familiar with it.
 [+] Dice rolls
 Agreed. It's useful for looking at all possible 'standard' (roll N dice and categorize the outcome) rolls. It's probably useless for more complex rolling rules. However, the OP's problem falls into the former category.
 [+] Dice rolls

rri1 wrote:
It may not be elegant, but these are the correct number:
6D6:
1 720 1.54%
2 28800 61.73%
3 14700 31.51%
4 2250 4.82%
5 180 0.39%
6 6 0.01%
46656
The first column is the number of dice that equal the mode (most common number of each roll).
The second column is the number for each type of roll: all different, pair, 3 of a kind, 4 of a kind...
The third column is the percentage.
To revive an old thread, I had a follow up question on the above 6D6 scenario. What are the odds of rolling two pairs of different doubles (i.e. not 4 or 6 of a kind)? Also what are the odds of rolling a pair and a triple (i.e. different numbers, that are not 5 of a kind)?
Thanks!
 [+] Dice rolls