Battle Calc Question

Cernel

I had to think about this for like half an hour because I wanted to know why @beelee's assumption was wrong and @redrum is correct and I believe I figured it out now:
The only mistake is a false assumption that adding the 2 probabilities is the same as throwing dice multiple times. According to that logic throwing at least a 1 or 2 a single time with 4 dice is 1/3 + 1/3 + 1/3 + 1/3 = 4/3 which is of course wrong for obvious reasons.
What you would need to do instead (if you don't want to calculate the probability of the event not happening as suggested by @redrum) is to add the probabilities of throwing 1/2, then 3-6 plus throwing 1/2, then 1/2 plus throwing 3-6, then 1/2
Which would be 2 * (2/3 * 1/3) + 1/3 * 1/3 = 4/9 + 1/9 = 5/9 as @redrum Already pointed out.

But yes, the name OddsCalculator is misleading, because it doesn't really calculate anything it just simulates battles and shows average results of those simulations.

I've said a bunch of times that the name should be changed to BattleSimulator.

RoiEX

@Cernel Ooor it should actually calculate the odds, which is what I'm proposing.
Because in theory we should expect the dice to not be rigged, and therefore the result should not differ ^^

redrum

@roiex I'm pretty sure the reason we simulate rather than trying to calculate the true odds is complexity and that you'd have to keep that code in sync with the actual battle rolling code if you did create it. Calculating the true odds for 1 round combat isn't too bad but once you expand this out to unlimited rounds of combat with units that have AA attacks, support attachments, etc, it becomes pretty crazy. In the end, I believe you'd have to create a giant tree with each round of combat being a level in that tree and the number of branches to the next level would be equal to the number of different casualty combinations for both sides.

The example above would be something like this:
round 0: (A 2 subs, D 1 cruiser)
round 1: [(A 2 subs, D 1 cruiser) - 22%], [(A 1 subs, D 1 cruiser) - 22%], [(A 2 subs, D 0 cruiser) - 56% - end]
round 2: [(A 2 subs, D 1 cruiser) - 5%, (A 1 subs, D 1 cruiser) - 5%, (A 2 subs, D 0 cruiser) - 12%], [(A 1 subs, D 0 cruiser) - 7%, (A 1 subs, D 1 cruiser) - 7%, (A 0 subs, D 1 cruiser) - 7%]
...

You'd have to probably expand the tree out until the probabilities get small enough to not really matter. Then you'd have to calculate all of the metrics off the probability tree you generated.

Cernel

@roiex This would be cool, but I would surely suggest you to keep the current BattleCalculator, rename it to BattleSimulator, and add another utility, called BattleCalculator, to do actual calculations. The reason being that with all the stuff going on I don't think it is really feasible to have the math to cover all cases (and there are a few cases not even fully covered by the current simulations, like the "isMarine" property) and that would be a terrible burden imposed to any further changes or additions, as, in any moment you do anything influencing calculation, you would need to update the actual BattleCalculator too (and I can see this really getting in the way of adding features).
Just based on how much having a BattleCalculator would disincentive adding any kind of additional combat features (think about AA guns specials), I would suggest to forget about it, even tho it is cool, in theory.
But it would be good if it would be just a subset, supporting only the most common feature, and retaining an alternative BattleSimulator (the current BattleCalculator) for more complex maps. Then, the BattleSimulator could even be absent default, and let the mapmakers of more advanced maps have it, if they think so. Say, you make a reduced BattleCalculator for Classic, Revised and v3, covering all those things that are pretty much set in stone, but TWW etc. keep using the simulations.

ssoloff

I guess that guys stuff is off or I misinterpreted it.

@beelee I don't think Ed Collins is wrong. As you said, it may just be a misinterpretation of his table applied to the stated problem ("what is the chance of rolling two dice and at least one die is a 1 or 2?"). Using the graphic Ed Collins presents for the 36 possible combinations of rolling two six-sided dice, if you count all the cells in which either a 1 or a 2 appear, you get 20. Thus, 20 / 36 = 0.5556, as @redrum and @RoiEX calculated via other means.

beelee

@ssoloff right on I come up with 24 ones or twos. Which ones should I not be counting ? Also I count 12 sixes in his example instead of 11.

When I do it the opposite way it all works fine.

ssoloff

I come up with 24 ones or twos. Which ones should I not be counting ?

@beelee The bold entries in the table below are the ones that should be counted:

:--:	:--:	:--:	:--:	:--:	:--:
(1,1)	(1,2)	(1,3)	(1,4)	(1,5)	(1,6)
(2,1)	(2,2)	(2,3)	(2,4)	(2,5)	(2,6)
(3,1)	(3,2)	(3,3)	(3,4)	(3,5)	(3,6)
(4,1)	(4,2)	(4,3)	(4,4)	(4,5)	(4,6)
(5,1)	(5,2)	(5,3)	(5,4)	(5,5)	(5,6)
(6,1)	(6,2)	(6,3)	(6,4)	(6,5)	(6,6)

Remember, you're counting pairs of dice, not the individual dice themselves.

prastle

@beelee simple finite = (1/6 +1/6) x 2dice = 66% without going into vast explanation.

beelee

@ssoloff Cool ! Pairs of dice was where I was screwing up. Thanks for the explanation : )

prastle

@beelee naw its more of the fact the extra hit isn't being counted in your ? Triplea is looking at hits that could matter.

prastle

@beelee it also isn't taking inot account subs have first strike ?

prastle

@beelee ah missed the one round of combat part

beelee

@prastle heh heh : ) I missed a lot more than that

How you doing brother ?

prastle

@beelee all good

RoiEX

@redrum I actually thought about how to implement it and it shouldn't really be that difficult at all.
Recursion should keep everything pretty simple.
If we can calculate the exact theoretical odds for a single round, we can easily calculate them for n+1 rounds by adding the probabilities of all possible outcomes together multiplied with the probability with each individual outcome.
But I may be wrong about this. Thoughts @ssoloff ?

redrum

@roiex Yeah, if you were to do it then recursion would be the way to go. You are correct that if you can do it for 1 round then its essentially the same calculation for each round. The things that would need proven out are:

Can we actually come up with a formula that does 1 round in complex/large battles (think 100 units vs 100 units with lots of different types of units with support attachments and AA attacks)?
Given that you may have to calculate for say 7-8 rounds of battle for these large battles, would it finish in a reason amount of time given how fast the tree expands?
Would this actually replace the existing battle calc and if not then how painful would it be to maintain it alongside the existing one?

Cernel

@redrum I surely suggest to keep both the Battlecalculator and the Battlesimulator, also considering that this is a volunteer based project, in which anybody can walk away anytime.

RoiEX

@Cernel What benefit would you see in keeping "both" variants?

Cernel

@cernel Side feature request, a think I sometimes thought is having a button on the simulator that allows you to show everyone the results and the units in the simulation. Like when you messed up something and would want to rerun the battle and edit it, of course at run count 1.

Cernel

@roiex

There may be things you overlook, like AA shots with special properties against infrastructure units or other things, and at least having a simulator would be more reliable if there is not always a developer around ready to cover all unforseen cases the mapmakers may get creative with.
Maybe a developer would add a feature, but would not be able to rework the battlecalculator; much easier adding features with a simulator; now you are requesting any developers that want to improve or change battle related things to be able to refactor the battlecalculator too; that is a huge additional requirement.
Already the simulator doesn't cover all cases, like you cannot add marine units and decide to take them in some numbers before or after; covering everything would be even more difficult with a calculator.
Maybe something in the future bugs off and there are no developers around to correct the problems readily; a simulator is much more reliable than a calculator, as it is not really another thing but what already happens in battle.