So I was scrolling through my Facebook feed and found an interesting little game posted by a friend.

The post in question was from a page called 'Relief Teaching Ideas' and they can be found by following the link.

Given my current mindset, which is craving some short term gains, I thought it would be interesting to sample the entire solution space and examine the success probabilities because that's the kind of nerd I am.

So first things first we need to break down the game into various stages.

- Generate two numbers (uniform random distribution) between 1 and 6.
- Choose a unique permutation of the two digits.
- Combine these two digits into a single number.
- Repeat Steps 1-3 until you have 3 of these numbers.
- Sum these 3 numbers.
- Check the result.

Now there are several things one could do here that are interesting little projects and in fact I might be inclined to a do a few of them in future (but I won't say what they are yet ðŸ˜›.

What I am going to do today however is to examine the complete set of results and do some simple analysis of the solutions.

In order to do this efficiently there are several aspects of the 'game' (which I am now going to ruin) that need to be changed in order to minimise the number of collisions that a random approach would encounter (though this is part of the 'game' aspect for now I'm just exploring the solutions).

When we look at this process without the randomness what we actually see is 'how many different numbers can we create for each of the repeated stages?'. This is a fairly easy question to answer so I'm gonna get to it ðŸ˜›.

Loading up the old faithful vim editor inside putty.

We know that the results of rolling one die is a number between 1 and 6 and in a fair dice that there is a uniform probability of getting any one result. According to the rules we need to do this twice. So first lets find a way to represent these two die rolls

Next we need to create an array for each of these numbers to be stored in for each round of number generation. Whilst we could create a single array for the entire game (we might get round to that in a later post) it makes the code much more readable to do it this way.

So what is wrong with this next picture?

Well I'd always encourage you to test code as you are writing it else you'd end up disheartened in the end.

Well it's pretty obvious that the first for loop doesn't include the full range of possible outcomes so we need to amend that in order to go forward. Once we've made the correction we can setup another for loop for the second die and we can add the results to the list we constructed to store the results.

Now we have the mechanism to generate every possible result of the dice rolls for each round of number generation but this doesn't yet tell us the number values of those results. Well that is the next stage.

We are going to use something you've probably not seen in a while but it's a rather useful tool to be able to understand especially when you start working with numbers using different bases.

The above table shows you how we represent base 10 numbers. By using the first element in the tuple as the 10s column and the second element as the 1s column we can construct our numbers and given that we want to be working with numbers we might as well do it inside our nested for loops.

According to the game rules we now have to repeat this process 3 times. Now we could just copy and paste this code to repeat it, changing the name of the list variable to get the results for each but this is an example of where we can make a function.

This function can then be used with very little effort to get the all possible results from each round (though as it stands at the moment these arrays are all the same because they lack any sort of variable behaviour).

The next step in the game is to add all these numbers together. That sounds like some more for loops to me.

That gives us a lot of results

How many of those are unique you ask?

And that's it. Simple enough right? Done ruining something now? Of course not...

## NOW FOR SOME GRAPHS!!!!!!

The most obvious and easily explainable behaviour that we can see here is due to fact that numbers with final digits greater than 6 are less common and impossible in the first round.

This is especially important when comparing against a modified version of the code generating digits between 0-9.

See the nice normal distribution arising from the modified results.