??Poker Copilot 2.58 is now available to download.
Added starting bankroll. You can set this in the Preferences. Bankroll charts start at this level.
Locating and dealing with problematic hand history files is much easier with the new “Hand History Problems” window. A link to this window appears when Poker Copilot has difficulty reading a hand history file.
Fixed a problem with Ongame hands where returned uncalled bets were sometimes miscalculated
Added a work-around for a new Winamax hand history problem – if a hand is labelled simply “holdem”, Poker Copilot assumes it is no limit holdem.
Export-generated tournament summaries with extra blank lines on end are now parsed correctly.
PokerStars 20-100 BB tables now work correctly with the HUD
Java 6 introduced the ability to run AppleScript from within Java. For a long time I considered this a solution in need of a problem. However I’ve been working recently on making it easier to find and report hand history problems in Poker Copilot. With a little bit of AppleScript I can open the Mail application, create a message, and attach a file. Java supplies the recipient’s email address, the subject, the body of the message, and the attachment. Put it together and it looks like the following:
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.
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?