Everytime I try to open your latest program, it shows up for a tenth of a second and then disappears. What am I doing wrong?

LOL, you never used a command line utility before, did you? :p

I was typing an explanation of how to use it, but I deleted it; I'm not sure it's a good idea to teach people how to open a command prompt... it has the potential to cause all kinds of trouble. :( If you have a little patience, I'll copy paste that code into a program with a graphical user interface (read: the kind you're used to) and let you play with it that way.

@Everyone else reading this: please take a look at the last post on the previous page, if you're at all interested in analysing the probability an attack will be successful, you want to read that.

Okay, that went quicker than expected. You can get the GUI version here. It's a hybrid; essentially it's the first version, with graphing capability torn out, the calculation routines replaced and (slightly less crucial) backspace working.

Unfortunately, I could not easily copy over the ability to show how it works, so here's a sample of that output:

Using straightforward calculation
[12 vs 8, 60% offence kill rate]
  Simulation              Simulation & Expected   Cumulative
  Kills     Chance        Kills     Chance        Chance
      0     0.0000            1.80  0.0000        0.0000
      1     0.0003            2.55  0.0000        0.0000
      2     0.0025            3.30  0.0000        0.0000
      3     0.0125            4.05  0.0000        0.0000
      4     0.0420            4.80  0.0000        0.0000
      5     0.1009            5.55  0.0000        0.0000
      6     0.1766            6.30  0.0000        0.0000
      7     0.2270        *   7.05  0.0114        0.0114
      8     0.2128        *   7.80  0.1703        0.1816
      9     0.1419            8.55  0.1419        0.3235
     10     0.0639            9.30  0.0639        0.3874
     11     0.0174           10.05  0.0174        0.4048
     12     0.0022           10.80  0.0022        0.4070

Success chance:   0.4070

The asterisks are there to point out the "interesting" part of the calculation; that's only really relevant for the optimised version I was working on which only did that part line-by-line (and the rest all together, using functions from the statistics package I was talking about earlier):

Using straightforward calculation (optimised version)
[12 vs 8, 60% offence kill rate]
  Simulation              Simulation & Luck       Cumulative
  Kills     Chance        Kills     Chance        Chance
   Less         ??         Too few  0.0000        0.0000
      7     0.2270        *   7.05  0.0114        0.0114
      8     0.2128        *   7.80  0.1703        0.1816
   More     0.2253          Enough  0.2253        0.4070

Success chance:   0.4070

The stupid thing is those statistical functions are relatively slow, so until you get to a few hundred attackers (yes, that makes the original table a few hundred lines long), the extra work to be efficient actually slows it down...

---

If you have any suggestions, please let me know. I don't want to make any promises, but I'll see what I can do.

Uuuhm. How are supposed to open that previous program anyway?
And your latest version works, but it gave some weird results.

With 100% luck, 6 attackers vs 4 defenders gives a chance of 54,43%
But 60 vs 40 gives 17,86%
And 600 vs 400 gives 0,04%
And, if you haven't guessed it already, 6000 vs 4000 gives 0,00%.

How does that make sense?

Moros, are you familiar with law of large numbers? That may make little sense to those who are not familiar with probability theory, but that is just an easy example of what happens to variation when we want to average out attacks on a given big sample...

You can try to run those calculations again this time with:
600 vs 361 and so on
600 vs 360 and so on
600 vs 359 and so on...

If you click here, my last post on the previous page will also show; it contains a lot of stuff I refer to in this post, so try to at least skim it before reading this post. Also, if you happen to be Fizzer, there's some questions I have for you in there.

---

Moros, thank you for your post, it shows such an analyser actually serves a purpose. :)

---

szwweningen is correct, but I'd like to give a little more background (you know me, founding member of PCOPOWLWHMAP3OEMPMTASL :p).

First, let's get rid of that 60% kill rate and make it 50%, that way, it's like flipping a fair coin (head or tails, "kop of munt"). Now, if you ask for 10 vs 6 you are asking the same question as "if I flip ten coins, what is the chance at least six of them come up heads". The answer is 37,70%, not incredibly likely (but then again, it shouldn't be; you're only expecting 5) but far from impossible. Does that agree with your intuition?

Now if you increase the numbers to 100 vs 60 the chance drops to 2,84%. That makes sense, doesn't it? You're only expecting 50, while last time you needed one "exception", now you need ten of them. Going to 1000 vs 600 shows as a 0,00% chance. It's actually not exactly zero, (so, in WL terms, a 1000 vs 600 attack with 50% offensive kill rate and 100% luck, could work, you'd better not count on it though). Looking at it the other way, if 1000 coin flips come up heads 600 times (or more), you'd start wondering whether it's a fair coin, right? But for 10 vs 6 you wouldn't.

If you try with 10 vs 5 (62,30%), 100 vs 50 (53,98%), 1000 vs 500 (51,26%), etc. you'll see numbers which your intuition might have fewer problems with. Now if we look at the details I can explain exactly what's going on:

Using straightforward calculation
[10 vs 5, 50% offence kill rate]
  Simulation              Simulation & Expected   Cumulative
  Kills     Chance        Kills     Chance        Chance
      0     0.0010            0.00  0.0000        0.0000
      1     0.0098            1.00  0.0000        0.0000
      2     0.0439            2.00  0.0000        0.0000
      3     0.1172            3.00  0.0000        0.0000
      4     0.2051        *   4.00  0.0000        0.0000
      5     0.2461        *   5.00  0.2461        0.2461
      6     0.2051            6.00  0.2051        0.4512
      7     0.1172            7.00  0.1172        0.5684
      8     0.0439            8.00  0.0439        0.6123
      9     0.0098            9.00  0.0098        0.6221
     10     0.0010           10.00  0.0010        0.6230

Success chance:   0.6230

Let me explain the format a little better. The first two columns are entirely about the simulation (what WL calls "luck"). It calculates the probability of, in this case, ten attacking armies killing x defending armies and shows how likely that is to happen. You see this nicely "mirrors" around the expected case of 5 kills. The reason for that is 8 heads is just as likely as 8 tails, which in turn is the same thing as 2 heads. (Making this easier to follow is why I'm using 50% kill rate so far!)

The second group of two columns then "adds" both the luck case and the expected case together. Since we're using 100% luck that leaves 0% for the expected case, so the third column is identical to the first. The fourth column is NOT the chance of that happening (that's still the same as in the second column), it is the chance of the attack succeeding (ehm, technically, the chance of all defenders getting killed, but if the number of attackers is larger than the number of defenders, that's the same thing). So, if the third column is less than the number of defenders, the attack will fail and the fourth column is zero (by the way, that's really a zero, not just something too small to display with four decimals). If the third column is at least equal to the number of defenders, that line represents a successful attack and the fourth column contains the same number as the second.

Using straightforward calculation
[100 vs 50, 50% offence kill rate]
  Simulation              Simulation & Expected   Cumulative
  Kills     Chance        Kills     Chance        Chance
  (..)
     48     0.0735           48.00  0.0000        0.0000
     49     0.0780        *  49.00  0.0000        0.0000
     50     0.0796        *  50.00  0.0796        0.0796
     51     0.0780           51.00  0.0780        0.1576
     52     0.0735           52.00  0.0735        0.2311
     53     0.0666           53.00  0.0666        0.2977
     54     0.0580           54.00  0.0580        0.3557
     55     0.0485           55.00  0.0485        0.4042
  (..)
Success chance:   0.5398

With 100 vs 50 the chances of any specific outcome become far lower. Because everything below 50 mirrors everything above it, but with the "mirror" (5 or 50) having a smaller chance the total chance of success also decreases. Play around with 9 vs 5, 99 vs 50, 999 vs 500, etc. and see if you understand why it behaves as it does. :p

The reason for that fourth column is when luck isn't 100%, for instance, 10 vs 5, 50% kill rate, 75% luck gives:

Using straightforward calculation
[10 vs 5, 50% offence kill rate]
  Simulation              Simulation & Expected   Cumulative
  Kills     Chance        Kills     Chance        Chance
  (..)
      3     0.1172            3.50  0.0000        0.0000
      4     0.2051        *   4.25  0.0513        0.0513
      5     0.2461        *   5.00  0.2461        0.2974
  (..)
Success chance:   0.6743

When we simulate (luck case) 4 kills, thanks to the expected case of 5 kills that becomes 4 * 0,75 + 5 * 0,25 = 4,25 kills. Now WLs uses a kind of rounding which seems strange at first but actually makes perfect sense, it rounds to 4 with 75% chance and to 5 with 25% chance. That means the line (4,25 kills) has a 0,2051 chance of happening and if it happens a chance of 0,25 of killing all defenders. In total this means a 0,2051 * 0,25 = (after rounding) 0,0513 chance of killing all defenders. (Don't worry about that rounding, that's only for showing the results; internally it uses something like 12 digits I think.)

When you go back to 60% offensive kill rate, you lose the symmetry, so things are a little more complicated to explain, but the essential idea behind it stays the same.

That ends probability theory lesson 1. :) Take great care though, because you're teacher got a 6 (for the non-Dutchies: the lowest passing grade) the last time he made an exam about this kind of stuff... (That's also why it took so horribly long to code; the capability to output that detailed list of probabilities is just one of a lot of debugging, sanity-checking and testing routines. And I verified many results both manually and/or against the WL's built-in analyser.)

---

To answer your first question, it's supposed to be run from the command line. Actually, Windows is kind enough to open a command line for you, run the program, then when it finishes (almost immediately) it's "helpful" enough to close it again. Once upon a time (Windows 2000, maybe even still Windows XP), you could tell Windows "don't bother, I'll close it manually", but on this Windows Vista machine (I'm guessing you're at least on Vista too?) I can't find that option anywhere. Besides, it wouldn't do you any good, since you still wouldn't be able to input the parameters (attackers, defenders, offence and defence kill rate, luck) it needs.

While I could explain you how to open a command prompt manually and run it from there (since it wasn't automatically opened it isn't automatically closed either, letting you actually see the output), I'm not sure if I should. While there's nothing wrong with it, it's something you're completely unfamiliar with (otherwise, as soon as I mentioned "command prompt" in my previous post, you would've known how to run it). Just to be clear, that's not a complaint or an insult or anything, just an observation; most people nowadays have never even seen it, only knowing Windows and its graphical user interfaces. The problem is that it can be a rather powerful tool and has a pretty steep learning curve; it takes a lot of explanation just to teach you how to run my little program and it will leave you in an environment quite capable of doing a lot of damage to your computer (especially accidentally deleting files is far too easy and it doesn't use the recycle bin, gone is gone).

If you're really interested in the only thing the command line can do which the GUI cannot (producing those detailed overviews of how it got its answer), just say so and I'll see if I can fix that.

The only problem is that, as far as I can tell, haXe has no support for extended precision floating point numbers;

The haXe gets compiled to ActionScript, so really you can use something if it exists in ActionScript too. But I doubt you'll find this in the box in either of them, since they're not typically used for this kind of thing. I imagine there are third party libraries that could be ported but I'm not familiar with any off the top of my head.

How well does your code work with doubles?

Also, for a faster reply, you can e-mail me at fizzer@warlight.net

How well does your code work with doubles?

I tried that a while ago, it screws up the nCr computation. I have some ideas which could potentially fix that, but I have to test how well they work; before I realised extended precision doesn't carry over to haXe (and hence, to anything built-in into WL), using an Extended was a quick and easy solution. But, I'll reinvestigate doubles and see what I can work up. (I love the extensive library coming with Delphi Pascal, haXe pales in comparison. On the other hand, the number of compilation targets haXe supports is impressive...!)

Also, for a faster reply, you can e-mail me at fizzer@warlight.net

No hurry, I have some other parts left to figure out. For instance, determining lower and upper bounds on "interesting" number of attackers (and defenders, given number of attackers); if I'm gonna work on this, I might as well get it right. (The built-in analyser does not seem to always get the lower and upper bound of the graph right when you deviate from 60%/70%/75%.)
If I ever really need an answer and you don't reply here (maybe because you missed a post or didn't see a question "hidden" in a wall of text), I'll email you. It's just I don't want to bother you with mails when there's no hurry whatsoever.

@Moros, to wrap your head around it a little more easily, use this link.

Set n=10, p=0.5, with Prob. X is at least 6.

Now compare that to n=100 and X is at least 60, as well as 1000/600.

You'll see the very different shapes to the graphs, leading to the percentages you found strange.

Well, I have nothing to say in this tread since I don't understand programming, but all I know is that you can tell enough from the current analyse screen to have a rough estimation and that will help me enough.

Lol last time i have 12 army attack 2 i have 11 left and became 1

Good point, back on topic, we can now exactly calculate which failed attack is actually the most improbable. :p
I'm getting a 0,9999966445568 chance of success for 12 vs 2 (assuming 60%/70%/75%), or 1 in about 300.000. Ouch...!
Do you still have the link for that game?

@Moros:
If you're still reading this: just because you're not a programmer doesn't mean you can't give input. You can still make suggestions for improvements. If you have an idea how to make it easier to understand for people who never had a statistics class that would be very helpful!

How well does your code work with doubles?

Fizzer,

Actually, it's not that bad. Here's a comparison:

                                        Double      Extended
    Max input size:                     1029        16378
    Worst rel. error [  990- 1000]      -15         -19
    Worst rel. error [ 1020- 1029]      -15         -18
    Worst rel. error [16370-16378]      N/A         -18

These are the results of running through the nCr calculation (essentially enumerating one row of Pascal's Triangle) and looking at the final result (which should of course be exactly 1, but in practice it's 1 +/- a small error). This is shown in the second through fourth line, where for instance "-15" means the relative error is "x * 10^-15" for some 0 < x < 1. Because the size of the error fluctuates a little between adjacent values I've shown the worst over a small interval.

Sure, the errors are a thousand times bigger, but they're still small enough. Even after summing 10.000 values with a 10^-15 error, you're still only up to a 10^-11 error (worst case, 10^-13 average case if I apply the sqrt(n) law correctly). Chopping things off at full percent points (like the built-in analyser does) or even at one-hundredth of a percent (like my demo program) is only sensitive to 10^-3 or 10^-5 errors, respectively, so there's plenty margin of error left I think.

Would you be okay with an analyser which only works up to 1029 attacking armies...? Remember, beyond that, it doesn't get inaccurate or anything, it completely refuses to work. On the plus side, this limitation is perfectly static and predictable; for 1029 it will always work and for 1030 it will always fail. In other words, this is not prone to unpredictable crashes; adding an if Attackers > 1029 then ShowMessage ( 'unsupported' ); reliably "solves" the problem.

---

The alternative would require porting that statistics library (or finding another one). Problem is, it uses some numerical approximations and I am not exactly qualified to properly test whether my modifications work; sure, I can throw a bunch of numbers at it (and compare them against results obtained with the original version), but I have no idea where the corner cases are.

---

Anyway, no hurry, if you want to carefully think about this it's perfectly okay, not like I don't have other projects which need working on. ;)

RvW, I know that it is not really too helpful and is somewhat pointless, but I was wondering something as I do not understand the programming language that you are using. Why is it that anything above 1,029 would fail to work? I would understand it if it was 1,023 to 1,025 due to binary. However, it seems to me that 1,030 would be alright. I will say that the deepest that I have gone into programming is learning about PHP, but it is a bit basic at times.

The programming language I'm using is a dialect of Pascal (Delphi Object Pascal to be precise), but actually, that has absolutely nothing to do with it. :p

---

---

I think there are two things you're possibly misunderstanding.

---

First, it's not the number of armies itself that is a problem; if that were the case you'd have a very good point. The problem is a calculation I'm doing with the number of attackers; halfway through that calculation, the numbers get big (and when I say big I mean absolutely, positively huge).
Are you familiar with basic statistics? Simulating an attack in WL is very much like repeatedly flipping a (weighted) coin, once for every attacker. When it comes up heads, a defending army is killed. Now, calculating the chance of all attackers killing a defender is easy: 0,60^n (where n is the number of attackers, and of course the 0,60 is assuming the default offence kill rate of 60%). Calculating the chance of not a single attacker killing a defender is also easy: 0,40^n. It gets a little more complicated when part of the attackers kill a defender and another part doesn't; the chance that happens is not simply 0,60^x * 0,40^y, you have to multiply with something usually called cNr ("n-choose-r"). Essentially I need the n'th row of Pascal's Triangle [1] to do the calculation for n attacking armies.
In theory it's a simple enough calculation, but the result get incredibly big very, very quickly. For instance, 4 nCr 2 = 6, 8 nCr 4 = 70, 16 nCr 8 = 12870, 30 nCr 15 ~= 1,551 * 10^8, 50 nCr 25 ~= 1,264 * 10^14, ... and the "easy" way to calculate them uses intermediate values which are much, much larger still. (Luckily, I can use an alternative way to calculate them without slowing the computation down. However, there's no easy way around storing the result itself, so when that gets to big, I'm in trouble.)
So when I say it works for 1029 armies, that's just the practical consequence; internally, I'm saying 1,4 * 10^308 is okay, but 2,8orso * 10^308 (which happens in the calculation for 1030 armies) is not.

[1] Note, both Pascal's Triangle and the programming language Pascal are named after the same mathematician Blaise Pascal, but there's no real relation between the two of them.

---

Secondly, while the numbers in Pascal's Triangle are integers, I am not storing them as integers, I'm using floating point numbers (that's were the whole "Extended" vs. "Double" question comes in; those are two "flavours" of floating point numbers). If you're not familiar with that word, it's very similar to scientific notation (such as "1,23 * 10^4", except that (this being computers ;) ) the exponent is in powers of 2 instead of 10).
Usually floats are used when you want to store non-integral numbers, but they have another purpose as well (which is my reason for using them): storing ridiculously big numbers. And I don't think "ridiculously" is exaggerated: double precision already goes up a little past 10^300, extended precision comes very close to 10^5000. To put that into perspective, the size of the observable universe is somewhere between 10^40 and 10^45 times the radius of an atom...!
To put it in another perspective, computers can usually work with numbers up to 4,3 * 10^9 (32 bit integer) or 1,8 * 10^19 (64 bit). On a 64 bit machine it is reasonably practical to work with 128 bit integers for a maximum of 3,4 * 10^38. Of course it's possible to go beyond that (and there are some programs which do), but around this time you should start wondering whether you really want to (and, in some cases, the answer can be "yes, there's no other way"!). In this case it turns out using floating point numbers is "good enough". But, that does mean it's very unlikely the maximum allowable numbers (even if you had thought about me doing a calculation with them) will sound unfamiliar to you. Just for fun, I looked them up in the docs: MaxDouble = 1.7e+308 and MaxExtended = 1.1e+4932.

---

Does this clear things up? If you have any more questions, just ask!

---

---

RVW: hwo to command promt

CMD.EXE

@Killer23:
Yeah I know (you really think I'm writing command line utilities if I don't know how to open a command prompt? :p ).

The point is, just firing up CMD isn't going to do you much good. You still need to get to the correct directory.
(Unfortunately, that's not trivial if you've never done it before, especially because MS's implementation of long filenames (read: spaces in filenames) is horribly broken, some directories show up in the graphical shell with a different name than they actually have ("RvW's Documents" versus "My Documents", aaaaragghghgh!!) and some other, smaller, issues.)
Also, completely at odds with the graphical environment, there are only very few instances where the command line asks you to confirm potentially disastrous commands. The fact that it defaults to setting the initial directory to be the system directory does not help either.

I didn't leave out the explanation because it's impossible to explain, I left it out because of the potential for causing unintended damage and because it was relatively easy to convert (almost) everything to a GUI program anyway.

---

ps. I didn't forget about this project, I'm just kinda low on time and I want to make absolutely sure I don't mess up.

I googled and found this thread after I had an improbable failure: 5v2 and 6v2 in turn 3, costing me a reinforcement card. This is a 1/1209 chance, which beats the original poster (1/567) but loses to the 10v2 loss (1/19,073).

Huge props to RvW for giving the formulas and posting the code.

With apologies I converted RvW's Pascal code to Perl; any mistakes in the conversion are obviously my own.

#!/usr/bin/perl
#
# Usage:
# $ wlcalc attackers defenders [offense defense luck]
#
# Default values for offense, defense, and luck:
# - offense = 0.6
# - defense = 0.7
# - luck = 0.75
#
# Algorithms taken from RvW's code:  http://warlight.net/Forum/Thread?ThreadID=3153&Offset=0
# and converted from Pascal to Perl.
#
###########################################################################

use strict;

my ($attackers, $defenders, $offense, $defense, $luck) = @ARGV;

$offense = 0.60 unless defined $offense;
$defense = 0.70 unless defined $defense;
$luck    = 0.75 unless defined $luck;


print "Attackers         = $attackers\n";
print "Defenders         = $defenders\n";
print "Offense           = ", &get_prob($offense), "\n";
print "Defense           = ", &get_prob($defense), "\n";
print "Luck              = ", &get_prob($luck),    "\n";

print "\n";

my ($attack_success) = &attack_success_chance($attackers, $defenders, $offense, $defense, $luck);

print "Chance of success = ", &get_prob($attack_success), "\n";
print "Chance of failure = ", &get_prob(1 - $attack_success), "\n";
print "Chance of failure = 1 in ", (1 / (1 - $attack_success)), "\n";

exit;


###########################################################################
# sub get_prob($prob)
#
sub get_prob {
  my ($prob) = @_;

  return ($prob * 100) . '%';
}	# sub get_prob()


###########################################################################
# sub attack_success_chance($attackers, $defenders, $offense, $defense, $luck)
#
sub attack_success_chance {
  my ($attackers, $defenders, $offense, $defense, $luck) = @_;

  if ($attackers == $defenders) {
    return &kill_all_chance($attackers, $defenders, $offense, $defense, $luck) *
      (1 - &kill_all_chance($defenders, $attackers, $defense, $offense, $luck));
  } else {
    return &kill_all_chance($attackers, $defenders, $offense, $defense, $luck);
  }
}	# sub attack_success_chance()


###########################################################################
# sub kill_all_chance($attackers, $defenders, $offense, $defense, $luck)
#
sub kill_all_chance {
  my ($attackers, $defenders, $offense, $defense, $luck) = @_;

  my ($ncr) = 1;
  my ($sum_chance) = 0;

  my ($expected_kills) = $attackers * $offense;

  foreach my $i (0 .. $attackers) {
    $ncr = ($ncr * ($attackers + 1 - $i)) / $i if ($i > 0);

    my ($sim_kills) = $i;
    my ($sim_chance) = $offense ** $i * (1 - $offense) ** ($attackers - $i) * $ncr;
    my ($total_kills) = (1 - $luck) * $expected_kills + $luck * $sim_kills;

    my ($total_chance) = $sim_chance;
    if ($total_kills <= $defenders - 1) {
      $total_chance = 0;
    } elsif ($total_kills < $defenders) {
      $total_chance = ($total_kills - int($total_kills)) * $sim_chance;
    }

    $sum_chance += $total_chance;
  }

  return $sum_chance;
}	# sub kill_all_chance()

i want to see a 100% luck 1% offensive kill rate 1000 VS 1000 succeed.
0.01^1000 success chance