Forum adverts like this one are shown to any user who is not logged in. Join us by filling out a tiny 3 field form and you will get your own, free, dakka user account which gives a good range of benefits to you: No adverts like this in the forums anymore. Times and dates in your local timezone. Full tracking of what you have read so you can skip to your first unread post, easily see what has changed since you last logged in, and easily see what is new at a glance. Email notifications for threads you want to watch closely. Being a part of the oldest wargaming community on the net. If you are already a member then feel free to login now.

Someone's reply about 'average statistics' in a post on math hammer got me thinking.
How does one really calculate the expected value for a bunch of dependet dice rolls?

The binomial distribution can certainly be used, since all the tests are either pass or fail, and the binary distribution function (bdf) has a defined expected value, but since the number of dice in subsequent testsis dependent on the outcome, I don't think multiplying Expected values will cut it.

It is almost like you would have to solve a series of large summations.


Any thoughts?

I'm not a mathematician, but s I understand it, the binomial distribution would only give the expected number of successes. Often we're just as interested in expected number of trials before a failure or other interesting number.

I think most posters (including myself) don't have the advanced mathematics skills necessary to calculate discrete distributions. Personally I just use simple means and fudge the distributions, bearing in mind informally that (1) some sets of trials have a wider variance than others and (2) people tend to interpret probabilistic means as necessary minimums (as in "it takes 3 glancing hits to down a wave serpent"), so it's necessary to compensate for that.

Expected values for the most part, brute force simulations also work if you have even rudementary programing skills.

Posted By der Wiskinator on 01/03/2007 1:51 PM
Someone's reply about 'average statistics' in a post on math hammer got me thinking.
How does one really calculate the expected value for a bunch of dependet dice rolls?

The binomial distribution can certainly be used, since all the tests are either pass or fail, and the binary distribution function (bdf) has a defined expected value, but since the number of dice in subsequent testsis dependent on the outcome, I don't think multiplying Expected values will cut it.

It is almost like you would have to solve a series of large summations.


Any thoughts?

Depends a little on what you're trying to do, but if what you're trying to do is something like work out the binomial distribution of killing a marine with a scatter laser, bear in mind that although each step has binomial distribution which affects the later steps (which would make this a hard problem), the probability of a success across the three steps is an acceptable probability as input for the binomial function.

In other words, you don't work out the binomial distribution of hitting, and then apply that to the binomial distribution of wounding, and so on, but simply work out the probability of hitting *and* wounding *and* killing, and then use that to work out the binomial distribution

As somebody who took a combinatorics course, let me to tell you: I don't remember anything about combinatorics.

What I do know, is that if you have a series of probabilities, each dependant on each other, you can simply multiply them out. Further, you can multiply the final odds of success by the total number of attempts and calculate an expected number of successes.

Thus, if you have a 2/3 chance to hit, a 1/2 chance to wound, and a 1/3 chance for the save to fail, one shot has a 1/9 chance to kill the target. If you shoot 9 times, you will kill one target, on average.

You could kill 9. You could kill 0. You could calculate the odds of either of those results. But the average result is going to be one kill. You should be basing your tactics on what the average effect of a given action will be, but it helps to know what the range of effects is as well. For example, if a given attack will always kill 1 model, no questions asked, no more, no less, that's very easy to plan around. If it will kill 5 on average, but is just as likely to kill none as to kill 10, that's hard to plan around.

Typically the TheoryHammer calculation says "5.2 dead MEqs" meaning that on average, a given attack will produce 5.2 dead models of T4, 3+ save. It might be nice to improve that to have some sort of range of variation, as well. Something like "the average is 5.2 dead MEqs, with 90% of all results falling between 4.2 and 6.2" or something to that effect.

I'm sure that has an actual technical name in prob/stats math, but I don't know what it is.

Cool
Thanks all. I may vary well build up some programs to test out the realities over a lot of trials to what we are talking about as 'averages'. Maybe we can figure out some metrics to talk about the range of fluctuation.

Well, mean, mode, and standard deviation are pretty handy, for starters...

I started work on a TheoryHammer .net application, but got sidetracked with other things. It's hard to write something like that without your scope creeping so far out of proportion to your time that it becomes impossible to complete. You keep thinking "Oh! I should add feature xyz..."

Yeah, that's what happened with some of my stuff. I'm somewhat working on rewriting it to handle statistics more gracefully. On my last run I just switched over to simulating the rolls ten million times after not coming up with a reasonable closed form for finite non-zero rerolls, rending, and Axes of Khorne all in the same set.

I don't recommend brute forcing your calculations. I suppose it works, but it's cleaner to try to represent stuff mathematically, or algorithmically.

I'm sure if I was smarter I'd know the math to calculate a lot of the stuff out in the most efficient ways, but even with my limited recollection of college, I was able to do a lot of what I needed.

You just have to bear the special rules in mind at each step in the hit-wound-save sequence, and run branched calculations if you have to, or examine all permutations.

For example, with a normal shooting sequence, you're looking at 3 D6 rolls, hit, wound, save... A total of 216 permutations. To calculate the outcome of each, and sum up the odds of various outcomes, is much less expensive than doing 10 million trials.

So, you end up with three nested for loops, 1 to 6, and each time you calculate the result and increment a "dead" or "not dead" counter. Then you put those values over 216 and there's your odds.

That's still a bit brute forcey, but not as bad as just running 10 million trials.

I have four computers on my desktop (or, at least, four which are connected to a trackball, monitor, and keyboard sitting on my desktop). The least powerful of them ticks 2.4 billion times per second.

The "expense" of ten million trials is laughable.

Really, that's how I started doing it until trying to get a comprehensive closed form handling finite non-zero rerolls, that's where the trickiness ensues. It just ended up being easier to have the hardware do the work -- at my self-imposed deadline, at least

And yet, you use a trackball...

I have a dozen or so, and I used to run them all, but a while back I got sick of the noise and heat of them all, and now I only run five.



Well, right, it's just a matter of response time in the application, and general sense of accomplishment.

When it comes to response times, 10 million trials isn't laughable. While I realize that a 2.4 ghz processor is entirely commonplace, you can't run a single trial in a single clock cycle, or even a hundred clock cycles. I'm not sure what sort of response times you were getting, but I'd expect a 10 million trial, brute forced approach to calculating a round of shooting, would take a couple seconds to complete. That's fine if you just want to check one thing... But what if you want to generate whole stat sheets with dozens of different situations and weapons compared? A couple seconds two dozen times isn't an acceptable amount of latency, especially when it's bred by programming shortcuts.

Also, as far as sense of accomplishment goes, I personally wouldn't find brute forcing the situation to be very rewarding. I know I can do it. I'm not writing a TheoryHammer tool to save time, I can do the math faster by hand... I'm writing it because it's a nice, compact requirement set to build a simple app around, and have some fun writing something clean and functional. It's not about getting the output numbers with as little thought as possible, it's about thinking about the math enough that some additional insight is gained.

But, that's me... To each his own.

Erm, did you read my post about optimal Chaos Lords?

After all was said and done, once I batched it all up, ran the numbers for every possible Chaos Lord offensive config, the next set was done before I got the previous one done. Finite non-zero rerolls is not trivial mathematically, and after spending enough time on it that I realized I could just simulate every possible Chaos Lord ten million rounds in less time, well, I did it...

At some point, I'm going to do it purely via math and set it up as a web application, but that's below other things on my spare time programming tasks (like, a web-based army list editor).

And feh, I've been writing code since 1981 and have the tendonitis (precursor to carpal tunnel syndrome) to show for it; trackballs are easier on my wrist

While 10 mil will take a while, you can alwasy run 100k in 1% of the time, and it will still be a large enough sample set to give you a fair indication on what to expect.

As far as a sense of accomplishment goes, I spend enough time at work looking to squeeze out efficiency in my code that for something that has next to no uptime, I don't mind slacking and waiting an extra few seconds instead of spending hours doing the computations to come up with the actual solution, that while more accurate will still still not be of any real use other than as a broad indicator.

That would be orders of magnitude more complicated than the most feature heavy TheoryHammer calculator... You're looking and hundreds of hours of dev time for something that can accurately reflect GW's list building rules.

As far as TheoryHammer, it's hard for me to picture the requirements you're working towards, but if you're just trying to get something done for the sake of getting it done, to answer the questions in one particular thread, then sure, brute force it.

The TheoryHammer application I envisioned writing would allow you to input a squad, and would then give you their effectiveness against MEqs, GEqs, perhaps a dozen different target types, and it would do it at 12", 24", 36", moving and not moving, plus a report for effectiveness against vehicles, etc. In this situation, if you're doing 10 million trials per average, then by the time you've done the whole page I'd guess it'd take several minutes on a typical machine.