Play Now Login Create Account
illyriad
  New Posts New Posts RSS Feed - Advanced Attacking: a work in progress
  FAQ FAQ  Forum Search   Register Register  Login Login

Topic ClosedAdvanced Attacking: a work in progress

 Post Reply Post Reply Page  <12345 7>
Author
 Rating: Topic Rating: 2 Votes, Average 5.00  Topic Search Topic Search  Topic Options Topic Options
Innoble View Drop Down
Wordsmith
Wordsmith


Joined: 06 Dec 2011
Status: Offline
Points: 141
Direct Link To This Post Posted: 03 May 2012 at 21:29
Oh, while we're on the discussion of rounding and the changes. I ran into a really annoying thing with my large forest report. I saw a legion of rats in the woods, scouted it, sent the armies and ran the report through my calculator. It predicted I should be losing 1013 charioteers. Part of my calculator copy-pasted down below:

Type Amount bonus(%) Casualties
Cavalry 1015 15 1013
0     0

But unfortunately:

Two opposing forces clash against each other.

Heavily wooded terrain spells difficulty for ranged units and cavalry. Infantry units find they have a large advantage here.

Like the attackers, these thick forests do not provide much assistance for anyone except your footsoldiers, who take great pleasure in the extra cover afforded to them.

Attackers:Unit:Quantity:Casualties:Survivors:
Commander: Heavy IKnights Knight1Damaged for 99, 147 health remains.
Troops:Charioteers Charioteers101510123
Commander: Heavy IIKnights Knight1Damaged for 99, 147 health remains.
Commander: Heavy IIIKnights Knight1Damaged for 99, 97 health remains.
Commander: Heavy IVKnights Knight1Damaged for 99, 187 health remains.
Commander: LightCharioteers Charioteer1Damaged for 99, 147 health remains.


Defenders:Unit:Quantity:Casualties:Survivors:
Troops:Elder Bucks Elder Bucks4594590
Troops:Ratlings Ratlings349134910
Troops:Rats Rats175417540
Troops:Diseased Rats Diseased Rats8748740

This really annoys me. I cannot explain the 1 extra survivor. I know noone probably cares if you can get that close, but I kind of want to know the exact calculations they use. This must have something to do with rounding, because my calculator predicts 1013,03 casualties. If it had been 1012,99 my calculator would have said 1012 too. So somewhere in some step in the calculation, the devs have set it to round in some way, up or down, left or right, who knows. The 0,04 difference you can actually achieve with a tenth of a ratling... thats how close it is.

It is impossible to explain this deviation with the terrain-modifiers as any change to those has a 10 to 100 times greater effect. You can't make it right that way. I have other large forest reports, also on the order of 500 troops sent against a legion and those did predict exactly, so it is a rare deviation only happening when things are *just* right for it. That's typical of rounding issues. 
Back to Top
Bartozzi View Drop Down
Greenhorn
Greenhorn
Avatar

Joined: 04 Jul 2011
Status: Offline
Points: 96
Direct Link To This Post Posted: 04 May 2012 at 05:09
FYI, I downloaded the docx to my mac (where the formulas didn't show up upon opening it); then imported it to SkyDrive, and it works perfectly. So anyone who doesn't have up-to-date software but has a Windows Live account should have no trouble.
Back to Top
HonoredMule View Drop Down
Postmaster General
Postmaster General
Avatar

Joined: 05 Mar 2010
Location: Canada
Status: Offline
Points: 1650
Direct Link To This Post Posted: 04 May 2012 at 15:39
That's a small enough error that it could be caused by a different order of resolution to the same equation.  You have to keep in mind that computers don't have such a thing as real numbers--they have "floating point" numbers which is a finite number system and this will cause slight deviations in calculated results from the mathematically true answer.

I haven't looked at your calculator (only your writeup on the algorithm and modifiers, both of which I personally believe are very accurate).  But you may need to adjust your implementation so that parts of the calculation using very small numbers and floating point calculation are saved for last.  The reason for difference could also be something like Excel and Google Docs using 32 bit floating point numbers while Illyriad uses 64 bits.  Again, the smaller the numbers involved, the more likely this would be to make such a small difference weven without doing something bad like dividing a number by 0.001.

The general rule is that, when order of combination of factors makes no mathematical difference, combine the largest factors first.  Also, keep denominators large, never applying division until you have them as large as you can get them, and minimize the number of multiplication/division steps performed.  For example, don't do 10/100 + 20/100 -- do (10+20) / 100.

http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems

Also keep in mind, that even if your calculator is well-designed, the Illyriad implementation may not be.  You'd have to guess the exact order and breakdown of calculation steps they performed in order to get the exact same results.


Edited by HonoredMule - 04 May 2012 at 15:44
"Apparently, quoting me is a 'thing' now."
- HonoredMule
Back to Top
Innoble View Drop Down
Wordsmith
Wordsmith


Joined: 06 Dec 2011
Status: Offline
Points: 141
Direct Link To This Post Posted: 04 May 2012 at 16:20
You make a lot of sense Honored Mule, thanks. I have been trying some things, but so far I have not been succesful with fitting this weird exception. I think your last two lines probably describe the problem best:

Also keep in mind, that even if your calculator is well-designed, the Illyriad implementation may not be.  You'd have to guess the exact order and breakdown of calculation steps they performed in order to get the exact same results.

I've found that I can fit the problem by rounding the defense to a certain digit and then not round the attack, or reverse, but it didn't make sense to me to do it that way. I doubt the problem is small enough to be explained with floating point numbers, because it was on the order of 1/100,000 which is still well within safe limits for those kinds of operations, but yea who knows what the Illy-server does with the numbers. Very hard to tell. 




Edited by Innoble - 04 May 2012 at 16:20
Back to Top
HonoredMule View Drop Down
Postmaster General
Postmaster General
Avatar

Joined: 05 Mar 2010
Location: Canada
Status: Offline
Points: 1650
Direct Link To This Post Posted: 04 May 2012 at 17:34
A difference of 1/100,000 is easily explainable by floating point inaccuracy, given that that level of error needn't be accomplished in a single step.  No typical single calculation with reasonable numbers would produce an error that large, but in 5 to 10 steps, it could even be much larger.  In fact, you could get an error of hundreds in about 3 steps if, for example, the first two steps erratically produced a small denominator which was then applied against a large numerator.

Consider the following real-world example, which doesn't even contain any calculation errors, but only shortcomings in representing the original numbers prior to calculation.  These are pseudo-32bit conversions, as the representation is limited to 32 bits but not in IEEE floating point format--there are no exponent bits.  But that is an advantage, actually allowing us to get slightly more accuracy in this particular example.

Consider 0.01.  In binary, it is the incomplete series 0.00000010100011110101110000101... which converted back to decimal is 0.00999999977648258.  Divide 100 by that and you've got an error of 0.000223517424996003816015028 in a single step.

Now suppose you divided 100 by 0.01 squared.  That division produces an error of 0.0447034854988011559760116 which is two hundred times worse than before.  If instead we started with the inaccurate representation of 0.001 (which we know to be 0.01^2), we'd have the same amount of error as when we divided by 0.01 (in this particular case, Windows calculator produces precisely the same error margin, likely due to both numbers having the "same" floating point representation with only the exponent changing).

The important point is that two small errors combined did not increase the error margin by a factor of 2 but 200.  I don't know that they are, but problems with number representation and floating point calculations can easily be fully responsible for the amount of error you're seeing.


Edited by HonoredMule - 04 May 2012 at 17:36
"Apparently, quoting me is a 'thing' now."
- HonoredMule
Back to Top
Innoble View Drop Down
Wordsmith
Wordsmith


Joined: 06 Dec 2011
Status: Offline
Points: 141
Direct Link To This Post Posted: 04 May 2012 at 17:53
Well explained, let's hope this is not the reason, because it would be very hard if not impossible to figure out how it happens and how to reproduce an error like that in a calculator program. 

Thankfully it is always just 1 extra dead guy out of many hundreds or 1 extra commander damage where you didn't expect it. It always seems to be in favor of the attacker too, so if you calculate a hit it shouldn't be a problem.
Back to Top
Salararius View Drop Down
Postmaster
Postmaster
Avatar

Joined: 26 Sep 2011
Location: USA
Status: Offline
Points: 519
Direct Link To This Post Posted: 04 May 2012 at 17:59
Innoble, very nice spreadsheet, thank you so much for posting this.  Because I am immensely impatient, I wrote a macro to more quickly figure large combat results.  If you are interested, the following macro runs in about 2 seconds for any size group (doesn't cut off at 2000, figures results for "few" to "cornucopia").  It doesn't minimize the same value you were minimizing but it calculates the least number of troops to win a battle.  If you find it useful, wonderful, glad to help.  If not, sorry to waste your time.  Again, thank you so much for sharing all your hard work!Clap

Sub Minimize_Casualties()
    inc = 1000
    Sheets("Calculator").Cells(4, 3).Value = 1000
    casualties = Sheets("Calculator").Cells(4, 15).Value
    Do
        total_offense = Sheets("Calculator").Cells(1, 15).Value
        total_defense = Sheets("Calculator").Cells(2, 15).Value
        If total_offense > total_defense And inc > 0 Then
            inc = Round(-1 * inc / 2, 0)
        ElseIf total_offense < total_defense And inc < 0 Then
            inc = Round(-1 * inc / 2, 0)
        End If
        If inc = 0 Then
            If total_offense < total_defense Then
                Sheets("Calculator").Cells(4, 3).Value = Sheets("Calculator").Cells(4, 3).Value + 1
            End If
            Exit Do
        End If
        Sheets("Calculator").Cells(4, 3).Value = Sheets("Calculator").Cells(4, 3).Value + inc
    Loop
End Sub

Back to Top
Innoble View Drop Down
Wordsmith
Wordsmith


Joined: 06 Dec 2011
Status: Offline
Points: 141
Direct Link To This Post Posted: 04 May 2012 at 18:25
Very cool Salararius, yours is much more effective and faster. Can't say I tried very hard in making my button, but even if I had I doubt I would have come up with something that good. 

Do you do this for a living? I only started to use vba a year ago to augment my work as a teacher.

I will put yours in for the next version.

Thanks!!
Back to Top
Yhina View Drop Down
Greenhorn
Greenhorn
Avatar

Joined: 04 May 2012
Status: Offline
Points: 61
Direct Link To This Post Posted: 04 May 2012 at 18:51
Some months ago i did some work to figure out terrain mods.. back then, the combat system would trunc casualties (pre-tournament combat system )

No much explanation on it, tho numbers are kinda self explanatory for those who have played with them before.. both combats took place in plains, attacking with pure spearmen, the first with 188 kobolds and the later with 182. Both with a kobold commander L 0.

Under Real is the combat report values (for wounds and casualties) and estimated what comes out by placing the numbers and using terrain mods..   so seems that spearmen got -15% penalty in plains for both attacking and defending.


Back to Top
Salararius View Drop Down
Postmaster
Postmaster
Avatar

Joined: 26 Sep 2011
Location: USA
Status: Offline
Points: 519
Direct Link To This Post Posted: 04 May 2012 at 18:52
Originally posted by Innoble Innoble wrote:

Very cool Salararius, yours is much more effective and faster. Can't say I tried very hard in making my button, but even if I had I doubt I would have come up with something that good. 

Do you do this for a living? I only started to use vba a year ago to augment my work as a teacher.

I will put yours in for the next version.

Thanks!!

Very good, it makes me happy to be helpful Big smile.  Helping people was one of the things I appreciated when I was programming.

The short answer is no, I don't do this for a living now.  With very few exceptions, programming is treated as a commodity service.  I'm too special CoolWacko to enjoy being a commodity. CryWink

Back to Top
 Post Reply Post Reply Page  <12345 7>
  Share Topic   

Forum Jump Forum Permissions View Drop Down

Forum Software by Web Wiz Forums® version 12.03
Copyright ©2001-2019 Web Wiz Ltd.