Blackjack Probabilities, Card Counting – Calculation and Simulation

I spent a few summers in the mid-90s card counting with a couple friends on summer vacation from college. Vegas was saturated so we focussed on Reno and Mississippi. I'm pretty sure we were about the only ones in Mississippi because the rules weren't always great (the basic rules are fixed of course but casinos can and do change the "edge cases" like the ability to double after splitting) and they played with big "shoes" of multiple decks, usually 8.

The thing is when you count you start at zero when the deck(s) are shuffled and then keep a running count. So it's just one number. Each card you see modifies the count up or down (we used the Omega II system where 10s were -2, aces and 8s were 0, 4/5/6 were +2, etc). Once you practice (a lot) it's not hard: I could count a double deck perfectly as fast as someone could push cards off the top.

The thing about playing games with a lot of decks is that they let players join at pretty much any point. In a single or double deck game you have to wait for the shuffle. So we could wander around the casino, wait for a (massive) shuffle and then start counting without playing. If the count got good, it could get really good, and once a bunch of "bad" cards were out it would stay good for a while. Long enough to jump in and play a few hands, until the count went bad and then you could pick up your winnings and move along.

Fun times. We made good money for college kids but never had enough starting cash to really make a splash and get caught.

I wasn't the first to discover this, although I once thought I was. About 1990, the Internet was not yet generally available. I was interested in Poker and Blackjack. Not in Roulette, it was clear that you always lose there. But in Blackjack - it was not so easy. I had many discussions with my friends. Then I wrote a program in C to work it out. The "expected value" was, as expected negative, but with the changing card stacks it regularly fell into the positive. I wanted to publish "my sensational discovery", but for various reasons I didn't get around to it, 5 years later, when I tried a new attempt, a short internet search showed that others had come to this result long before me ...

Now many years later comes the next attempt to publish it. In the meantime I have made the beginner programming language Easylang, which is also quite well suited to show mathematical concepts and programs on the Internet.

And, I haven't been to the casino in years and have never counted cards there.

About 10 years ago I was in Vegas at the Riviera (now demolished). At the time it was on the cheap end of the strip and tried to attract customers by offering very attractive odds on games. They had a blackjack table that was single-deck, and they would deal pretty deep before shuffling. Those are ideal conditions for an amateur card counter like myself.

But the real kicker was, they had a side game that paid out extra bonuses for blackjacks. Blackjack paid like 5-1 on the side bet, suited AK BJ paid like 20-1, etc. I'm forgetting the exact payouts.

That night I built a simple spreadsheet to analyze the game, and calculate the effect on expected value of removing a card from the deck. I discovered that if they dealt 8 cards without an ace, the side bet became profitable. If they dealt two hands without an ace, it became wildly +EV.

I cleaned up the next morning. Really surprisingly, they never cut me off, even though the dealer made some snide remarks about card counting and I didn't make much effort to hide my strategy.

Some card counters use two counts, to separate odds from strategy. I could never imagine myself memorizing all those cutoff numbers. These two counts aren't independent; once you establish a 2-dimensional parameter space, the regions of interest aren't going to be defined by coordinate cuts. They're going to be blobs. But for some of us visual thinkers, blobs are easier to remember than a table of cutoff numbers.

I never wrote the code to compute this strategy, back in 1990. Today it would be easy. If what I said is obvious to you, have a go at it?

A card counting scheme is essentially a gradient vector, simplified to varying degrees to be memorable and practical. One takes the gradient at a full deck. Should one design the second count based on a gradient taken elsewhere, such as the typical imbalance when the whale comes over to bet?

Better, the 2-dimensional projection should be allowed to evolve in simulation. A pair of gradient vectors is a good initial seed, but only that. And a strategy based on "blob" charts will evolve differently than a strategy based on cutoff numbers, potentially realizing greater gains.

> So, in blackjack, you can win if the circumstances are right and you have a lot of time.

> If the "true count" is at least 6, we bet $1000, otherwise $10.

If you bet like that in a casino in Nevada, they would kick you out so quickly you wouldn't have time to count your chips. In Atlantic City they can't kick you out, but they can shuffle the deck after every play.

And nowadays almost every blackjack table uses auto shufflers that basically makes it like a new deck on every hand, which is why I don't play much blackjack these days.

A great website solely focused on calculation and simulation. That in-depth explanation left me wondering about the nature of the game itself. I'll probably try to play blackjack if I have the chance.