Saturday, March 31, 2012
Thursday, March 29, 2012
Just the lies, no statistics
I noticed a link to this article on TheBack40K's blog roll. It was pretty basic probability theory stuff, but I noticed an error in his calculations.
He had calculated the probability of a Sherman killing a Stug at range as 5.5556 percent. This is correct, but when he applied it to a whole platoon firing ten shots he said the probability was 55.556 percent. Or, that you would kill "Half a Stug." This is wrong. You don't just multiply the probability on one thing by ten to get the probability of one thing happening in ten chances.
A correct way to determine this is to use a binomial probability calculation. If you do this you get the probability of at least 1 kill as 43%. At least 2 kills is 10%. At least 3 Kills is 1.5%. I even pointed him to this handy online calculator to figure out these probabilities very quickly.
Basically, I was just telling him his math was wrong and showed him how to correct it.
He responded:
Never mind that in his article he said that:
But, you're giving the wrong impression about the odds. You say that you should kill half a stug, but that's not useful. If they see 3 of their stugs die when they where confident that not even one should die, you haven't really helped them. It's more useful to say that approximately half the time you will loose at least one.
He had calculated the probability of a Sherman killing a Stug at range as 5.5556 percent. This is correct, but when he applied it to a whole platoon firing ten shots he said the probability was 55.556 percent. Or, that you would kill "Half a Stug." This is wrong. You don't just multiply the probability on one thing by ten to get the probability of one thing happening in ten chances.
A correct way to determine this is to use a binomial probability calculation. If you do this you get the probability of at least 1 kill as 43%. At least 2 kills is 10%. At least 3 Kills is 1.5%. I even pointed him to this handy online calculator to figure out these probabilities very quickly.
Basically, I was just telling him his math was wrong and showed him how to correct it.
He responded:
Hi CaulynDarr,So he thinks that being able to quickly get the wrong answer is better than being able to quickly get the right answer.
The purpose of Expected Value is to give you a rough calculation for tactical purposes. It will not give you the exact percentage chance to kill one or more StuG's (in this case).
The main reason for using EV's over Binomial Calculations in Flames of War is that it gives you a single value instead of a set of values, allowing you to compare results between disparate sets of information (eg. Standing RoF vs Moving RoF). The second reason is that, with practice, you can begin to calculate EV's on the fly - or at least approximate them.
If you want to work out Binomial Calculation on the fly, then go for it - this class is not for you :D
Never mind that in his article he said that:
I should also mention that these types of equations should all be worked out before each game - taking 10-20 minutes to figure out the exact odds in the middle of a round might negatively impact your Sportsmanship score!My response:
But, you're giving the wrong impression about the odds. You say that you should kill half a stug, but that's not useful. If they see 3 of their stugs die when they where confident that not even one should die, you haven't really helped them. It's more useful to say that approximately half the time you will loose at least one.
With a smart phone and the link I provided, you can figure these values out on the fly.
His counter-response is a bit longer, so I'll just summarize. He says that since the chance of loosing a Stug is less than half then he's not worried about the loss of any more Stugs. This is exactly the misconception I warned about in my response. I was trying to show that loosing one Stug is an average coin toss, and losing more than one is in the realm of possibility. The math he provided makes it look like Stugs are nigh invincible compared to Shermans when in half of your games you'll be loosing 1 or 2 a turn. Half is less than one, and saying you will kill half a Stug can easily be misinterpreted as you shouldn't be able to kill any. A bit different than saying that in 1 out of 10 volleys you will probably lose 2 Stugs to a single volley from a platoon of Shermans. In fact, over the course of 10 volleys you will probably loose 5 or 6 Stugs. If you start playing around with the number of Shermans and the number of kills you are wanting to get, you can learn some real interesting things.
He then goes on to say that my math may be more accurate, but is less useful. BS! More data is never less useful. Not my fault if you can't comprehend the additional information.
Then someone dumps this useful gem:
So comments are only for stupid inane stuff, not for, you-know, useful comments.
The article was to teach people how to do statistics in the context of a miniature games. It's wrong and counterproductive to point out that you are teaching bad statistics? Who do you think is doing the more harm here?
If you are going to write an article about statistics, do the homework and get it right. At least point out where you are fudging the numbers. People get so bent out of shape when they play miniature games and unlikely stuff happens. It's a bad understanding of probability that causes it, and this article just propagates the same misunderstanding of probability and statistics that is all too common.
BTW, the only appropriate comments to this post are to tell me how awesome I am, or to ask me how I manage to be so awesome.
His counter-response is a bit longer, so I'll just summarize. He says that since the chance of loosing a Stug is less than half then he's not worried about the loss of any more Stugs. This is exactly the misconception I warned about in my response. I was trying to show that loosing one Stug is an average coin toss, and losing more than one is in the realm of possibility. The math he provided makes it look like Stugs are nigh invincible compared to Shermans when in half of your games you'll be loosing 1 or 2 a turn. Half is less than one, and saying you will kill half a Stug can easily be misinterpreted as you shouldn't be able to kill any. A bit different than saying that in 1 out of 10 volleys you will probably lose 2 Stugs to a single volley from a platoon of Shermans. In fact, over the course of 10 volleys you will probably loose 5 or 6 Stugs. If you start playing around with the number of Shermans and the number of kills you are wanting to get, you can learn some real interesting things.
He then goes on to say that my math may be more accurate, but is less useful. BS! More data is never less useful. Not my fault if you can't comprehend the additional information.
Then someone dumps this useful gem:
Just a friendly reminder.. the 'Comments' on posts are for quick questions and 'thanks!' type stuff. Remember no 'counter-articles' to the articles. If you want a long discussion, please head over the the forums and write pages and pages of point/counter-point til your little fingers bleed. Enjoy!
So comments are only for stupid inane stuff, not for, you-know, useful comments.
The article was to teach people how to do statistics in the context of a miniature games. It's wrong and counterproductive to point out that you are teaching bad statistics? Who do you think is doing the more harm here?
If you are going to write an article about statistics, do the homework and get it right. At least point out where you are fudging the numbers. People get so bent out of shape when they play miniature games and unlikely stuff happens. It's a bad understanding of probability that causes it, and this article just propagates the same misunderstanding of probability and statistics that is all too common.
BTW, the only appropriate comments to this post are to tell me how awesome I am, or to ask me how I manage to be so awesome.
Thursday, March 15, 2012
Kickstart My Heart for Legos
Do you like Legos? Robots? Miniature Games?
If you don't, why are you reading my blog?
Otherwise, Kickstart this!
If you don't, why are you reading my blog?
Otherwise, Kickstart this!
Monday, March 5, 2012
Cowboy Coding at the Indy Open
A few weeks ago I decided that I was in too much of a rush to get my Tau ready for Adepticon much less even earlier for the Indy Open. I still wanted to be involved, so I let Spag know that if he needed any help running the tournament my services where available. I thought I would end up helping judge, building terrain, or playing as the ringer. Of course, I ended up as keeper of the spreadsheet.
It started when Spag emailed me asking if I had a laptop. I told him I didn't have one, but I did have Numbers on my iPad. After explaining to him what that meant, I had him email me the Excel spreadsheet he had created for managing the tournament. Luckily the only thing that didn't load into Numbers was Microsoft's default font. What I didn't think about at the time was that there was no scripting in the spreadsheet to generate parings, or to output ordered rankings. That realization was an unfortunate "Oh Sh*t" moment. Especially since the stripped down version of numbers available in iOS doesn't support scripting. I certainly didn't want to do pairings for a 64 person tournament by hand. Especially since I was also going to be the designated ringer.
I've been planning on getting a new laptop for a while. I've also been wanting to learn Objective C programming since mobile development has become an increasingly demanded skill these last few years. I had settled on buying a Mac Book Pro in April. Ostensibly as a present to my wife because she's letting me go to Adepticon on her birthday weekend. So I dropped by the Apple Store in Castleton the weekend before last and finally pulled the trigger.
Spag left it up to me on how to pair up the players, so I set about writing a script to handle just that. I mostly program windows desktop apps and web apps, so I wasn't familiar with Apple's AppleScript or Objective C languages yet. I have used a little Ruby before, and Ruby has interpreters for OS X. It even ships with one installed, but I had to be a geek and go pull down the latest and greatest.
Last Wednesday night I spent a few hours coding up a script to perform the pairings. It could read in a CSV export of the spreadsheet and generate a random pairing in the first round or pairings based off of win/loss record and battle-points for any other round. It was not my most elegant coding work, but it was good enough to get the job done.
I was all ready to go Saturday morning. After getting the spreadsheet updated for last minute additions and no-shows, my script spit out the first round pairings without a hitch. Second round was where things started to go off the rails. I had made the assumption that I would not have to worry about players playing each other more than once. Since the tournament was strait winners vs winners, you couldn't have a looser come back and play someone who beat them. That would be true if there where an even number of winners after each round in the tournament. Otherwise you need at least one winner to play a looser. In this case, it's a possibility that the one winner who has to play a looser could play a person he already beat. So we needed to do a few manual player swaps to overcome this in a few rounds.
The next hurdle had to do with ever changing requirements. I had written my matcher to not just operate off of the number of wins, but the order of wins. So only a person with a 'wlw' would only play someone else with a 'wlw', not just a 2 and 1 player versus another 2 and 1 player. I didn't know when I wrote the script that Spags wanted to put everyone with the same number of wins in individual brackets on the second day. I had to update my script to try and pair all the people with the same relative records together. This was easy enough; I changed my script to count wins instead of match a concatenated string of 'w's and 'l's. This gave me a list that was ordered close enough to the individual brackets that Spag wanted. Some people got bummed up to higher brackets to make sure that we only had one bracket with an uneven amount of players. I had to do much more player swapping as we ended with many more players playing former opponents.
My script couldn't have been changed so easily to do the 6th round pairings. I needed to pair players who had been placed into the 4-1 bracket with other players in the same 4-1 bracket. I was the ringer the fifth round, and didn't have time to write a new script. I had to do the final round's pairing by hand. Fleshy humans are not very efficient at that sort of thing.
Luckily, we had a player drop from the final round. This freed me up to add a method to my script. It could now crunch the numbers one last time and generate the final results. I ordered by record and then by overall score for the bracket prizes, and then just by overall score to get the RenMan winner.
It would be nice if there was some tournament software out there that could tackle some of the issues that we faced. You need to use something other than spreadsheets to handle the complexity and variations on player pairing in larger tournaments. A more purpose oriented user interface would also help prevent data entry errors, and could automatically sanity check results. I believe Battlefront has something for running FoW tournaments, but I think its tailored to their style of tournament play. I would like to see something that was generic and could also leverage mobile devices. Tournament software that could be distributed and allow any tournament staff member with an iPad or iPhone to enter results or painting scores would be very cool. It would be a cool project to work on, but a lot of effort for something that would only potentially be used by 2 or 3 events in a year.
It started when Spag emailed me asking if I had a laptop. I told him I didn't have one, but I did have Numbers on my iPad. After explaining to him what that meant, I had him email me the Excel spreadsheet he had created for managing the tournament. Luckily the only thing that didn't load into Numbers was Microsoft's default font. What I didn't think about at the time was that there was no scripting in the spreadsheet to generate parings, or to output ordered rankings. That realization was an unfortunate "Oh Sh*t" moment. Especially since the stripped down version of numbers available in iOS doesn't support scripting. I certainly didn't want to do pairings for a 64 person tournament by hand. Especially since I was also going to be the designated ringer.
I've been planning on getting a new laptop for a while. I've also been wanting to learn Objective C programming since mobile development has become an increasingly demanded skill these last few years. I had settled on buying a Mac Book Pro in April. Ostensibly as a present to my wife because she's letting me go to Adepticon on her birthday weekend. So I dropped by the Apple Store in Castleton the weekend before last and finally pulled the trigger.
Spag left it up to me on how to pair up the players, so I set about writing a script to handle just that. I mostly program windows desktop apps and web apps, so I wasn't familiar with Apple's AppleScript or Objective C languages yet. I have used a little Ruby before, and Ruby has interpreters for OS X. It even ships with one installed, but I had to be a geek and go pull down the latest and greatest.
Last Wednesday night I spent a few hours coding up a script to perform the pairings. It could read in a CSV export of the spreadsheet and generate a random pairing in the first round or pairings based off of win/loss record and battle-points for any other round. It was not my most elegant coding work, but it was good enough to get the job done.
I was all ready to go Saturday morning. After getting the spreadsheet updated for last minute additions and no-shows, my script spit out the first round pairings without a hitch. Second round was where things started to go off the rails. I had made the assumption that I would not have to worry about players playing each other more than once. Since the tournament was strait winners vs winners, you couldn't have a looser come back and play someone who beat them. That would be true if there where an even number of winners after each round in the tournament. Otherwise you need at least one winner to play a looser. In this case, it's a possibility that the one winner who has to play a looser could play a person he already beat. So we needed to do a few manual player swaps to overcome this in a few rounds.
The next hurdle had to do with ever changing requirements. I had written my matcher to not just operate off of the number of wins, but the order of wins. So only a person with a 'wlw' would only play someone else with a 'wlw', not just a 2 and 1 player versus another 2 and 1 player. I didn't know when I wrote the script that Spags wanted to put everyone with the same number of wins in individual brackets on the second day. I had to update my script to try and pair all the people with the same relative records together. This was easy enough; I changed my script to count wins instead of match a concatenated string of 'w's and 'l's. This gave me a list that was ordered close enough to the individual brackets that Spag wanted. Some people got bummed up to higher brackets to make sure that we only had one bracket with an uneven amount of players. I had to do much more player swapping as we ended with many more players playing former opponents.
My script couldn't have been changed so easily to do the 6th round pairings. I needed to pair players who had been placed into the 4-1 bracket with other players in the same 4-1 bracket. I was the ringer the fifth round, and didn't have time to write a new script. I had to do the final round's pairing by hand. Fleshy humans are not very efficient at that sort of thing.
Luckily, we had a player drop from the final round. This freed me up to add a method to my script. It could now crunch the numbers one last time and generate the final results. I ordered by record and then by overall score for the bracket prizes, and then just by overall score to get the RenMan winner.
It would be nice if there was some tournament software out there that could tackle some of the issues that we faced. You need to use something other than spreadsheets to handle the complexity and variations on player pairing in larger tournaments. A more purpose oriented user interface would also help prevent data entry errors, and could automatically sanity check results. I believe Battlefront has something for running FoW tournaments, but I think its tailored to their style of tournament play. I would like to see something that was generic and could also leverage mobile devices. Tournament software that could be distributed and allow any tournament staff member with an iPad or iPhone to enter results or painting scores would be very cool. It would be a cool project to work on, but a lot of effort for something that would only potentially be used by 2 or 3 events in a year.
Subscribe to:
Posts (Atom)