I create an update of Poker Copilot by running a build script in Terminal. It takes a couple of minutes to complete, so I often start it running then godosomethingelse. If only I could be easily notified when the build script is complete…like if the computer could speak to me and say “build complete”… On Mac OS X this is easy. From Terminal you can type
say "build complete"
and your obedient Mac will do just that. So the last line of my build script tells the Mac to speak to me. Perhaps better would be:
Here’s the problem: To use FullTiltPokerFR (the France-specific Full Tilt Poker) you need to have an address in France. Which I don’t have. So I’m unable to test whether the FullTiltPokerFR support I’ve added this week works.
Here’s what I have been able to test: importing hand history files and tournament summaries.
Here’s what I haven’t been able to test: auto-detection of hand history files, and the HUD.
So please tell me, when you select from the Poker Copilot menu “Tools” -> “Detect Casinos…”, does it find your FullTiltPokerFR hand history folder correctly? (It will be listed under Full Tilt Poker).
Does the HUD work, for cash games and/or for tournaments?
If you’re a politician, admitting you’re wrong is a weakness, but if you’re an engineer, you essentially want to be wrong half the time. If you do experiments and you’re always right, then you aren’t getting enough information out of those experiments. You want your experiment to be like the flip of a coin: You have no idea if it is going to come up heads or tails. You want to not know what the results are going to be.
And on errors in computer programs:
No matter how good you think you are, the industry standard is that if you write 100 lines of program, there’s probably going to be one error in it.
I found out a few days ago that a heavily-used computer system I helped develop 11 years ago had a bug all that time, but which only revealed itself last year. I suspect the bug lay in code I wrote. For 10 years, the particular feature worked as expected, and was used every day. And yet it was broken all along.
Okay, that’s my example, but I am a mere mortal at programming. What about the immortals? Well there is Joshua Bloch, Java guru, who literally wrote the book on effective Java, and who wrote significant parts of the Java libraries. A couple of years ago he discovered that Java’s binary search method was broken. This method, which he wrote, had a bug which lay undiscovered for 9 years. Bloch’s conclusion:
The general lesson that I take away from this bug is humility: It is hard to write even the smallest piece of code correctly, and our whole world runs on big, complex pieces of code.
Once you accept that your code is almost certainly wrong, you become a better programmer. Instead of feeling insulted when someone finds a bug in your code, you feel grateful that you get the chance to fix the bug and make your code stronger. You try to make it easy for bugs to reveal themselves with as much useful information as possible. You code more carefully, you use static analysis, you believe in code reviews, you appreciate comprehensive testing, and you encourage people to report problems.
To my customers in France and Madagascar who play on FullTiltPoker’s France-specific software: could one of you please send a couple of FullTiltPokerFR tournament summary files to me to help with my testing? You’ll find them in your FullTiltPokerFR hand history folder – should be in Documents/HandHistory I think.
Loyal Poker Copilot customer Matt took a look at Poker Copilot’s odds calculation in the hand replayer. He has this suggestion:
Is there a way this can be set up to run against ranges based on stats? We know the villains VPiP and PFR. In some cases we have sample size issues, but we have the information so we’re not really playing against 4 random hands. We’re against 4 ranges that can be applied to villains based on known stats.
Nothing is perfect (aside from seeing hole cards lol). And some villains are more positionally aware, etc. Every is dealt a random hand. But once they make a decision pre-flop, it would be great if the replayer odds were calculated on a more accurate limp, and PFR hand range based on the stats we have. Would be like a built in Stove or Poker Cruncher iPhone app odds calculator.
Again, not sure if this is possible. But the odds calc in the replayer as it is now, while cool, isn’t taking advantage of the stats info we have. And I still have to run Poker Cruncher calcs with the player to estimate something much closer to my real odds/equity in the hand. It could also be misused by a player who doesn’t understand “Stoving” ranges based on stat percentages. Odds in the replayer may be closer than they appear lol. Say we’re in the hand with all villains VPiP under 15 and PFR under 10.
When they limp they aren’t playing a random hand. The biggest problem is players who are positionally aware. But I still feel like we’re getting a lot closer to our real equity in the hand by applying a 15% limp range for that villain vs. a random range. Likewise when that player raises with a PFR of 5% we’re against a much tighter range.
Your thoughts? Is this feasible? Is this desirable?
I’ve spent considerable time this week at the kitchen table playing multi-way hands of poker with myself with piles of 1-cent coins for stacks. This helped me create various split pot scenarios and contemplate how best to handle calculating all-in equity value. Sometimes the best way to solve a programming problem is to get away from the computer and instead deal with something quite concrete.
What’s changed:
Added support for new PokerStars 20-100bb tables
Improvements to All-in EV Calculator – works much better with split pots
Added odds of winning a hand to the hand history replayer
What’s fixed:
Fix for Winamax hand histories – small blind amount was being recorded as being big blind amount
Winamax Tournament hand histories are now recognised and imported
Fixed bug where Poker Copilot was sometimes swapping the button and big-blind in Cereus Network rooms heads-up hands
Changed bankroll chart to use longs instead of ints to avoid overflow problem for people who win lots in play money rooms