Given two positive integer inputs, a (attacker army units) and d (defender army units) return the probablity of victory (from 0.000 to 1.000) to +- 0.02 accuracy. The rules are given below for those unfamiliar with the game.
In the board game RISK battles are determined by the conflict of armies, namely the attacking army and the defending army. The results is determined as follows: the attacker rolls 3 six-sided die and the defender rolls 2 die. The highest two numbers of each player are compared respectively, and the higher number wins (this means the opposing army loses one unit). In the case of a tie the defender wins. For example:
Attacker has 10 units Defender has 10 units
Attacker rolls [6 3 2] Defender rolls [4 3]
The first comparison is attacker - 6, defender - 4. Since the attacker is higher, the defender loses one unit. Hence Attacker has 10 units, Defender now has 9 units.
The first comparison is attacker - 3, defender - 3. Since the defender is higher, the attacker loses one unit. Hence Attacker has 9 units, Defender now has 9 units.
This is continued until either the attacker has only one unit left, in which case the defender wins the battle; or the defender has no units left, in which case the attacker wins the battle.
This is one further rule: the number of die any player may roll cannot be more than the their units in case of the defender, or their units + 1 in case of the attacker.
Example: Attacker has 3 units, Defender has 1 units.
Attacker rolls 2 die (3 - 1), Defender rolls 1 die.
Can you double check your values, Jeremy? I've run your sims against a couple of on-line Risk calculators, and they're coming up with different values for some of your test cases. For example, the one at http://recreationalmath.com/Risk/ using 10 attackers and 10 defenders comes up with 0.47993525647768026, which doesn't meet your error criteria.
Thanks, James, you were right - I generated the values myself with a Matlab script. Unfortunately I did not do enough simulations - 10000 doesn't always get within 1% accuracy. Have updated them all now and rescored all solutions too.
Your solution is now the leading solution btw :)
I didn't submit a solution yet...mainly because I couldn't match up your test values and wanted to make sure that the problem wasn't on my end. (Most of the time, it is! :-)
I've got a working submission now, but you'll need to check the high end of the size chart for it. As usual, Richard and Alfnie are far more clever than I.
James, you give me too much credit. The next ot best solution was a very minor tweak to Jeremy's random solver. My larger solutions, 250, find the exact solution recursively.
James, your speed is impacted by recalculating previously evaluated cases. A case of 100 v 100 finished in ??
You're correct. It is inefficient with super-large armies. I was going for an exact solution (which was an offshoot of the original problems I had with the test suite), and recursion seemed to be the best way to do it.
As our resident "Get this problem to run faster" expert, do you think setting up a global m-by-n matrix with previously calculated probabilities would help things?
suggest writing script to produce testsuite of more cases to paste into cody
Yes, I am enlarging the test suite. Thanks for the input!
605 Solvers
5529 Solvers
466 Solvers
07 - Common functions and indexing 1
293 Solvers
157 Solvers