Advanced Attacking: a work in progress |
Post Reply | Page <12345 7> |
Author | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Innoble
Wordsmith Joined: 06 Dec 2011 Status: Offline Points: 141 |
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:
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.
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. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Bartozzi
Greenhorn Joined: 04 Jul 2011 Status: Offline Points: 96 |
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.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
HonoredMule
Postmaster General Joined: 05 Mar 2010 Location: Canada Status: Offline Points: 1650 |
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 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Innoble
Wordsmith Joined: 06 Dec 2011 Status: Offline Points: 141 |
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 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
HonoredMule
Postmaster General Joined: 05 Mar 2010 Location: Canada Status: Offline Points: 1650 |
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 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Innoble
Wordsmith Joined: 06 Dec 2011 Status: Offline Points: 141 |
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.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Salararius
Postmaster Joined: 26 Sep 2011 Location: USA Status: Offline Points: 519 |
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!
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 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Innoble
Wordsmith Joined: 06 Dec 2011 Status: Offline Points: 141 |
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!! |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Yhina
Greenhorn Joined: 04 May 2012 Status: Offline Points: 61 |
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. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Salararius
Postmaster Joined: 26 Sep 2011 Location: USA Status: Offline Points: 519 |
Posted: 04 May 2012 at 18:52 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Very good, it makes me happy to be helpful . 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 to enjoy being a commodity. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Post Reply | Page <12345 7> |
Tweet
|
Forum Jump | Forum Permissions You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum |