True odds calculator

[djensen]

Here’s a post on the Avalon Hill forum regarding true odds calculations:
http://boards.avalonhill.com/showthread.php?t=710

[Motdc]

That looks long enough and detailed enoght to read not when I’ve had a drink or two.  Thanks for the link, I’ll check it out this weekend!

Mot

[frood]

@Motdc:

I’ve never done any PHP, what language is it similar to?

Mot

http://en.wikipedia.org/wiki/PHP I think will tell you what you want to know. PHP is a scripting language that was developed in C, so I think the syntax may be similar to C, but I don’t know C.

It is easy to learn, as I picked it up on my own and have no other programming knowledge other than BASIC and Turbo Pascal from high school in 1992-1994.

[djensen]

It’s most like Perl.

@Motdc:

I’ve never done any PHP, what language is it similar to?

Mot

[Motdc]

I’ve always thought that the creators of Perl got together and said:  “You know, all those funny puntion marks never get used enough, lets create a progarmming language where you have to use every funny symbol on the keyboard.  We’ll make a killing selling replacement SHIFT keys when they get worn out from being used in every third character typed while coding”

:-D

[Dash_Riprock]

I made a calculator in a non-internet based Java application that runs the simulation 1 mil, 4 mil, or 16 million times divided by the number of units in the battle, depending on the settings.  So, for instance, if you run a battle with 10 units on each side on high accuracy, it will run 800000 times in about 5 seconds, and come within 1/10th of a percent every time.  And Java is even considered slow compared to other languages like c++.

Your problem, Frood, is just that its going to run allot slower on an internet based program, unless there is some alternate language or method that works better. I guess it ends up being a trade-off between accuracy/time and convenience.

[frood]

@Dash_Riprock:

I made a calculator in a non-internet based Java application that runs the simulation 1 mil, 4 mil, or 16 million times divided by the number of units in the battle, depending on the settings.  So, for instance, if you run a battle with 10 units on each side on high accuracy, it will run 800000 times in about 5 seconds, and come within 1/10th of a percent every time.  And Java is even considered slow compared to other languages like c++.

Your problem, Frood, is just that its going to run allot slower on an internet based program, unless there is some alternate language or method that works better. I guess it ends up being a trade-off between accuracy/time and convenience.

Does your sim handle submarines and abort conditions and such? I think those things really slow it down too.

Not that it matters, do you REALLY need to know to an accuracy of 1% or less?

[Dash_Riprock]

@Frood:

Does your sim handle submarines and abort conditions and such? I think those things really slow it down too.

Not that it matters, do you REALLY need to know to an accuracy of 1% or less?

Yes, it does, to the best of my understanding of the rules, and I think I have everything down right.  The only real problem it has that I know of is that the IPC lost details assume that units always die in the same order, so it just gives the results in numbers of units remaining, but in the case of AA guns and subs, this is not always the case.  I didnt think of that, though, until later and I dont feel like changing it now.  Not that its really a big deal, since it doesnt affect the actual chances.

As far as the accuracy thing, well, I didnt really think it was necessary either, but apparently some people want it REALLY accurate. :-)

[frood]

I’d like to build a Java version of AACalc, but sadly I do not speak Java :(

A Java app would have much greater portability, obviously. What yours lacks is some of the flexibility and detailed output that AACalc generates. I’d be interested in collaborating on a java-based tool.

True Odds calculation would be even better, if we could do that. Maybe me, you and Mot could all contribute - Mot seems to understand the math involved in true odds calculation.

[Dash_Riprock]

Im not really that interested in this anymore, but I could give you the source if you want and you can do whatever you want with it-I warn you though, it wasn’t exactly designed for anyone else to read.

BTW you know there are more options and results in separate windows right?

[frood]

No I hadn’t noticed. (runs to check) Hey that’s cool! Except the bar graphs do this transparent thing that shows whatevers behind the window there, it’s very distracting.

I wouldn’t mind playing with the source, be a good way to learn Java maybe. PM me for my e-mail addy.

[Motdc]

@Frood:

I’d like to build a Java version of AACalc, but sadly I do not speak Java :(

A Java app would have much greater portability, obviously. What yours lacks is some of the flexibility and detailed output that AACalc generates. I’d be interested in collaborating on a java-based tool.

True Odds calculation would be even better, if we could do that. Maybe me, you and Mot could all contribute - Mot seems to understand the math involved in true odds calculation.

I’ve done some Java and I am slightly tempted…once we are in the fall and things get more sane…hmmm…

[newpaintbrush]

http://en.wikipedia.org/wiki/Pascal’s_triangle

oo pascal u secksy fiend, you cut down calculation time so much . . . leaves time for other things.

Maybe if we get nekkid pix of Jen then I can be um, inspired, to write a true odds calculator.

[newpaintbrush]

@djensen:

I would like to see a true odds calculator. The problem is that my math is rusty and I’m not sure how to handle complex probability calculations such as would be required for Axis & Allies.

Anybody good with probability computations? I just need help with the math.

I have already figured out that a true odds calculator should use memoization otherwise large complex battle computations will take as long as a dice simulator. (Memoization is basically caching results of previous calls to a function for future use, it’s perfect for these math related operations).

Honestly, I dunno wat a “memoization” is.

I will say tho that large complex battle computations take a lot LONGER than a dice simulator.

Me am Dice Simulator.  Me say “You hit twice.”

Me am Large Complex Battle Computer.  Me say “You hit 20%.  You miss 30%.  Ur enemy hits 15%.  35% of time scenario repeats.”

Here’s wat u do (simple)

First you get Microsoft Excel and someone that knows how to plug in formulas and stuff and use concatenation etc.  Then you put the first 100 or so lines of Pascal’s triangle into a big array of arrays.  (So the first array element of the array of arrays will be “1”, the next will be “1, 1”, the next will be “1, 2, 1”)

You need to do this because it cuts down on calculation time a lot.

Then you write the bit that gets the user input.

Then you split the user input into types.  Like, let’s say that the user input is “3 infantry 1 tank attacking 2 infantry”.  You split that into “3 attacking infantry”, “1 attacking tank”, and “2 defending infantry”.

Then you use Pascal’s triangle to generate a list of possible outcomes for each of those types.  Like let’s say you attack with 3 infantry.  You have a (1/6) ^ 3 to hit 3 times, a 2 * ((1/6)^2*(5/6)) to hit 2 times, a 2 * ((1/6)*(5/6)^2) to hit 1 time, and a (5/6) ^ 3 to hit 0 times.  You can see the Pascal’s triangle element; “1, 2, 2, 1” here.  (You can use combination mathematics, but just making a fat Pascal’s triangle array is a lot more efficient on calculation time).

Okay, so once you have a list of possible outcomes for each of those types, you multiply the attackers list together (and give the appropriate output), and then you multiply the defenders list together (and give the appropriate output).

Now, there’s a certain probability that nobody will get a hit.  If you want to rerun the battle if nobody gets a hit on the first round, or report the result, whatever.  But realize that you can’t ask the program to “resolve” an unresolvable battle.  If you don’t write in something to account for the probability that nobody gets a hit, you could stick your program into an infinite loop.

Easiest way to do it is to make each probability outcome fraction (use fractions, not percentages for in-program calculation) have a common denominator.  Then you whack out the probability of all missing, and add up the remaining numerators to get a single denominator.

I’d do it myself, but I need nekid Jen pix for inspiration . . .

[Motdc]

@Frood:

I’d like to build a Java version of AACalc, but sadly I do not speak Java :(

A Java app would have much greater portability, obviously. What yours lacks is some of the flexibility and detailed output that AACalc generates. I’d be interested in collaborating on a java-based tool.

True Odds calculation would be even better, if we could do that. Maybe me, you and Mot could all contribute - Mot seems to understand the math involved in true odds calculation.

Hey Frood, I’ll be on vaca next week.  While sitting on the beach I might have a chance to skecth out in Java psuedo-code the implementation I was describing before.  I’ll let you know how I make out, if I get far enough to be useful then we can collaborate.

Mot

[frood]

With all due respect NPB, I think the problems you raise can be dealt with.

1. Battle rounds with no hits can be ignored, because it is as if they never happened. The exception is that if it is the first round, it may allow an opportunity for the defender to submerge subs.

2. Ultimately there are only a relatively small number of possible outcomes. There are a great many paths leading to those outcomes, but they can be collapsed into each other using certain programming tricks that I have an inkling of and that I think Mot knows how to pull off.

Even if it only works for smaller battles, it would still be worthwhile I think. The added benefit would be that it would be downloadable but still provide the same kind of output as AACalc (at least that’s my hope)

[newpaintbrush]

@Frood:

With all due respect NPB, I think the problems you raise can be dealt with.

So u got teh nekid Jen pix?  Anyways, I never said the problems were insurmountable, not by any means.  It’ll just take a bit of time and effort (looks around vaguely while zaphod beeblebroxing towards door . . .)

1. Battle rounds with no hits can be ignored, because it is as if they never happened. The exception is that if it is the first round, it may allow an opportunity for the defender to submerge subs.

They shouldn’t be ignored.  First, no hits is a possible outcome that should be representable when requesting outcomes after (x) rounds of combat.  Second, it is EASIER to calculate the no-hit probabilities as well as the hit probabilities with the Pascal triangle.  It is so much easier, that I think it probable that instead of eliminating the no hit probability (as I originally outlined), it may be better to put in an error catch routine and use Pascal triangle multiplication on the whole thing.

2. Ultimately there are only a relatively small number of possible outcomes. There are a great many paths leading to those outcomes, but they can be collapsed into each other using certain programming tricks that I have an inkling of and that I think Mot knows how to pull off.

OoOOoOOooOO what are these programming tricks? Are they language specific, or just general programming guru stuff?  I program a bit myself . . .

Even if it only works for smaller battles, it would still be worthwhile I think. The added benefit would be that it would be downloadable but still provide the same kind of output as AACalc (at least that’s my hope)

[Motdc]

Hi guys.  I’m back from vacation but I’m still ctaching up with work and emails and all that.

I’ll definitely takes a look at your links and ideas, newpaintbrush, as anything to help optimize the odds calculation is a good thing.

I’ll post again once I’ve got my head above water.

Later!
Mot

[Motdc]

@newpaintbrush:

@djensen:

I would like to see a true odds calculator. The problem is that my math is rusty and I’m not sure how to handle complex probability calculations such as would be required for Axis & Allies.

Anybody good with probability computations? I just need help with the math.

I have already figured out that a true odds calculator should use memoization otherwise large complex battle computations will take as long as a dice simulator. (Memoization is basically caching results of previous calls to a function for future use, it’s perfect for these math related operations).

Honestly, I dunno wat a “memoization” is.

I will say tho that large complex battle computations take a lot LONGER than a dice simulator.

Me am Dice Simulator.  Me say “You hit twice.”

Me am Large Complex Battle Computer.  Me say “You hit 20%.  You miss 30%.  Ur enemy hits 15%.  35% of time scenario repeats.”

Here’s wat u do (simple)

First you get Microsoft Excel and someone that knows how to plug in formulas and stuff and use concatenation etc.  Then you put the first 100 or so lines of Pascal’s triangle into a big array of arrays.  (So the first array element of the array of arrays will be “1”, the next will be “1, 1”, the next will be “1, 2, 1”)

You need to do this because it cuts down on calculation time a lot.

Then you write the bit that gets the user input.

Then you split the user input into types.  Like, let’s say that the user input is “3 infantry 1 tank attacking 2 infantry”.  You split that into “3 attacking infantry”, “1 attacking tank”, and “2 defending infantry”.

Then you use Pascal’s triangle to generate a list of possible outcomes for each of those types.  Like let’s say you attack with 3 infantry.  You have a (1/6) ^ 3 to hit 3 times, a 2 * ((1/6)^2*(5/6)) to hit 2 times, a 2 * ((1/6)*(5/6)^2) to hit 1 time, and a (5/6) ^ 3 to hit 0 times.  You can see the Pascal’s triangle element; “1, 2, 2, 1” here.  (You can use combination mathematics, but just making a fat Pascal’s triangle array is a lot more efficient on calculation time).

Okay, so once you have a list of possible outcomes for each of those types, you multiply the attackers list together (and give the appropriate output), and then you multiply the defenders list together (and give the appropriate output).

Now, there’s a certain probability that nobody will get a hit.  If you want to rerun the battle if nobody gets a hit on the first round, or report the result, whatever.  But realize that you can’t ask the program to “resolve” an unresolvable battle.  If you don’t write in something to account for the probability that nobody gets a hit, you could stick your program into an infinite loop.

Easiest way to do it is to make each probability outcome fraction (use fractions, not percentages for in-program calculation) have a common denominator.  Then you whack out the probability of all missing, and add up the remaining numerators to get a single denominator.

I’d do it myself, but I need nekid Jen pix for inspiration . . .

Got it.  That is a handy shortcut.

[frood]

Propellerhead Alert!!! :lol: