1. April 2009 BEATING BLACKJACK CARD COUNTING FEASIBILITY ANALYSIS THROUGH SIMULATION

2. Outline  The Hype: Why I Chose This Project  Project Objective  Background  The Game of Blackjack  The Basic Strategy  Card Counting Strategy  Simulation Questions  My Model  Assumptions  Development  Screen Shots  Findings  Verification / Validation  Limitations & Future Work

3. Background: The Hype ® All rights reserved to the original authors and producers

4. Project Objective  Simulate the game of blackjack and the proposed card counting strategy to determine if it is possible to actually make money doing this and if so, how much.  Determine how different degrees of human error effect monetary outcome.

5. Background: Blackjack  Player gets two cards (to start, both face up)  Dealer gets two cards (only one is face up)  Player decides whether take another card or not  Objective is to have cards total as close to 21 as possible without going over  Aces are worth 1 or 11  J, Q, K are worth 10  Whoever is closer to 21 (player or dealer) at the end wins  No money moves on ties (“push”)  Dealer goes last  If player goes over (“busts”) he/she automatically looses  Two card Blackjack (Ace, Ten) pays the player 3:2

6. Background: Basic Strategy  1962 (revised 1966): Thorp exposes simulation derived strategy  Millions of hands simulated (not so impressive anymore)  This strategy, deemed “The Basic Strategy,” setup a set of rules explaining what the best move for every given scenario is.  Basic strategy was later revised to account for the 6 and 8 deck “shoes” instead of 1 deck games.  Puts player at 0.57% disadvantage  Less than one percent… slow loss rate

7. Background: Basic Strategy

8. Background: Card Counting  Blackjack: A game with memory  With a finite number of cards per “shoe” each card that comes out during play, tells you a little more about what’s left for next hand. IE: If twenty four 5’s come out with a 6-deck shoe, we know no more 5’s can come out until a re-shuffle happens.  6 Deck Shoe: Memorize 312 Cards? Not Exactly.  High / Low Counting System 2,3,4,5,6  Add 1 to Count 10,J,Q,K,A  Subtract 1 from Count  Use count to determine next bet. [Bet a lot when probability is high for player. Bet minimum when probability is low for player.] Weigh count’s meaning based on number of decks left High count = higher probability of player win (because blackjack pays 3:2)

9. Questions To Answer  The model should answer the following questions:  What is the rate of loss playing perfect basic strategy?  What is the rate of gain (if any) playing perfect basic strategy and deploying the high/low card counting system flawlessly  Is it possible to make millions using these methods?  How does human error affect the outcome?

10. Model Assumptions  One player vs. One dealer  Simplification of varying number of players at the table depending on day, time, & location  Time to play 1 million hands  IE. counting with a team of people playing over the course of several months  Assumes no casino detection  Shuffling truly is a random process

11. Model Development  C# Development  Load cards into a deck array  Load decks into a shoe array  Shuffle entire shoe randomly  Deal cards to player and dealer  Player plays by basic strategy to determine next move  Dealer plays by blackjack standard rules to determine next move  Winner gets paid  Player bets based on deck adjusted count (“true count”)  When end of shoe marker (“cut card”) comes out, shoe is reshuffled  Win, Loss, Push, Blackjack and Bankroll stats are recorded

12. Screen Shots: Before Run

13. Screen Shots: After Run

14. Findings: ROI

16. Verification  Careful code revision and testing in parts  Tested card counting, basic strategy, and betting modules separately before integrating.  Printed details of 500 hands and manually reviewed each to ensure that the program was applying the appropriate rules and performing proper accounting.  Sent code out to a few friends for peer review  Verified against published basic strategy statistics  v1.0 was producing results that were 0.02% off from documented values (when running basic strategy simulations only) Discovered a minor logic error in basic strategy code

17. Limitations & Future Work  Limitations:  One player per table  Lots of hands played  Truly random shuffles  Team play not accounted for  No bankruptcy (lowest bankroll can be negative)  Error rates only account for miscounts not for basic strategy errors.  Surprising result when including error.  Future Work:  Simulate team play  Incorporate hide bets and “cover plays”  Model how people come and go from tables  Calculate total time for a team to play x hands.

18. Questions / Ending Remarks  Code is checked into SourceForge for anyone who wants to check it out. http://sourceforget.net/projects/cardcounting