Saturday, May 9, 2009

One of the features that I'm planning for my card counting site BarracudaFix is a way for users to pick a card counting system and learn it. I want the software to provide indicators of what the running count is and how the user should be altering their bets to maximize their advantage. I'm thinking that initially the end user should be able to browse several systems and pick one that provides a statistical advantage but has only a few rules to learn. Later as they become stronger players they can move up to a more sophisticated system.
This leads naturally to the concept of back testing. The idea for back testing is that I program the system to play blackjack using different fixed strategies. Then I record the results in a database table and average it over a few thousand runs. Then for each strategy I can present a graph to give the users an idea of how they can expect to fare.

Some of the strategies that I'm thinking about starting out with are:
  • Playing using the dealer's fixed rules
  • Random hit, stand, double & split (when allowed)
  • Correct Basic Strategy
  • Several 10 count card counting strategies that work by altering the bets
  • Adaptive basic strategies that change the basic strategy
  • Strategies that involve combining the 10 count betting and the adaptive basic strategies
  • A 'perfect' strategy where the betting is optimal and each play is optimal based on the cards seen so far
  • Strategies that are as close to perfect as the player is able to obtain but also include moves that are designed to avert suspicion. Splitting 10s is a good example of such a move. Normally you should never split 10s but in certain circumstances it can be a 'cheap' way to make the casino management think you are just lucky etc.

I coded a system to sit in an infinite loop and at each pass:
  • calculate a bet
  • be dealt a hand
  • look up the correct play
  • play the hand out and let the dealer play
  • print out the current bankroll
I was really expecting to see the dollar amount fluctuate but eventually rise higher and higher. I wanted to let this code run for several hours, come back and see how well the player had done. Instead I saw it lock up after only a few seconds each time. To me it looked like a classic deadlock but there was one problem - I wasn't using multiple threads. This was all coded in a single tight while loop. I used tools like jconsole and jvisualvm to try and detect deadlocks or just provide a thread dump to show me where in my code I was hung.
There were no deadlocks detected but I did notice that my own code was consistently hung up either doing string concatenation or some operation on a list or set. I started recoding my app to use more primitive constructions so that it looked less and less like Java and more like C but it would only move the the spot where the code would hang to a new location in the source.
Anyway at this point I thought I was dealing with a bug in the jvm, I tried downgrading my version of java, I started to rewrite the entire system in php and ruby etc.
Anyway what finally helped out was to add a Thread.sleep(50) inside my loop. I still don't understand what exactly is going on when the hang up occurs but it appears to be a thread starvation situation.
So I'm back on task to add those simulations that I discuss above. Look for them in the coming weeks!

No comments:

Post a Comment