Blackjack hand calculator

Hi Wizard and people. I saw on the Wizard of odds page, a blackjack hand calculator. Im justo so curious, cause im working on my homework consistent in doing this exact same thing. The point that got me curious, is that to calculate this odds for a hand, there has to be a recursive function, wich takes much more time to calculate than the wizard takes, even though the code is already optimized. So i wanted to know if there is somo algebraic direct way to calculate those odds, cause recusivley seems impossible to achieve the "BJ hand calculator" times. Thank you for your atenttion. Spanish aint my first language.

Quote: Hackergambler

… to calculate this odds for a hand, there has to be a recursive function …

I think a reference database was created based on exhaustive analysis. The work is done once instead of each time the same hand is analyzed. A simple database lookup beats a recursive algorithm every day of the week.

I dont think that is the case, beacause the database needed to save all the cases for 8 decks is enormous, petabytes-sized, just google would be able to do that. And for second, every time you click "calculate" on the wizard calculator, it takes a little time to calculate, it is not immediate, and even the "harder" hands take even more time, so im pretty sure it does calculate it on live. Thanks for your replay

It is possible to list all of the possible hands for blackjack in a composition dependent way. The only place recursion is necessary is on split pairs (and resplitting of split pairs.)

I have a series of spreadsheets that does just that, although it is only accurate out to 5-6 places.

All of the posible hands is an enormous number, if im not wrong there are about 10^16 posible hands-specificdeck compositions. Its not a sustainable solution to make that data base. I think i dont understand what you mean? Could u explain me please?... every time you hit another card now the crupier is going to "play" with a different deck, so to analize all posible ways of playing (to choose to hit or stand) you have to consider that hitting or standing has an effect on the crupiers hand development... please elaborate a little bit more for me, thanks for the reply.

I don't think there's any trick to it. My advice: Write your simulator in a compiled language (C, C++, Rust, Go) and it should run in less than a second, even if you don't use any clever tricks.

Well, actually, if you don't care about five-card Charlie, you can do memoization. Just keep a hash table of (hands, deck state) -> EV. This cuts the runtime down by a fair bit, since while recursing you'll automatically skip transpositions.

I'd check out the Wizard's video (I can't post links) on how to do it in Excel and then just implement this in your language of choice; it isn't harder than it looks to adapt it to finite decks. I got it working in less than a day.

I think there's an open-source calculator written in Java out there somewhere, though I don't have the link. If it's performant, it should be easy to just study it to see how the sausage is made.

Here's the key to the spreadsheet approach that I have used.

Given the dealer is showing a Ten and
Given the number of Aces, and 2s, and 3s . . .9s, and Tens left in the deck/shoe (a vector with ten entries), write a set of algebraic algorithms for the possible dealer outcomes (given that he is starting with a ten), namely
- the probability dealer will get a 17
- the probability dealer will get a 18
- the probability dealer will get a 19
- the probability dealer will get a 20
- the probability dealer will get a 21
- the probability dealer will get a BJ
- the probability dealer will go bust, which is = (1 - the sum of the other probabilities)

Once you define a player hand (say, T-2-6 vs 10), you then update the composition of the shoe and calculate the probability of the various dealer outcomes as shown above, which allows you to calculate how often this player hand wins, loses and pushes.

Writing algebraic algorithms for dealer outcomes becomes much harder (more tedious) when the dealer upcard is an Ace or a 2. You may choose to omit those scenarios in which the dealer requires, say 7 or more cards, to make his hand. This limits the accuracy of your calculation but the EV results will still be accurate to 4 or more significant places.

The way I did it was to create a hash based on the composition of the hand. For instance you can only have a maximum of 21 Aces, or 10 Twos, 7 Threes etc. in a hand. So create a set of numbers so each possible hand creates a hash.

Then starting with hands that have 21 cards (obviously only 21 Aces), work out the chances of winning if you stand on this. Then, using recursion, look at hands of 20 cards both when they stand and then when they hit. You gradually work back via fewer cards in the hand until you have the EVs (stand or split) of all the possible hands.

If you're really fussy you repeat the same given you have split a number of hands (e.g. EV of 3T vs 2 when you've not split, similarly 3T when you've split 33, split 333, split 3333.) I think most people stop at that stage.

Places to fall over are the probability of the next card given not only what's gone but also if you know, because of peeking, some cards the dealer doesn't have (so you're slightly more likely to get if you hit).

Quote: charliepatrick

Then starting with hands that have 21 cards (obviously only 21 Aces), work out the chances of winning if you stand on this. Then, using recursion, look at hands of 20 cards both when they stand and then when they hit. You gradually work back via fewer cards in the hand until you have the EVs (stand or split) of all the possible hands.

link to original post

Can't you stop (well, start) at 11 cards, and work your way down?

Quote: Dieter

...Can't you stop (well, start) at 11 cards, and work your way down?...

No - you have to start at the longest possible. For instance in the UK, where you don't split Aces vs A, you could have eight Aces, then a 4, then more Aces. Also, for some games, you get a bonus for multi-card 21s, so you might hit 17 which would be a 14-card hand. In regular BJ you could get A2AAAAA (7-card soft 18 vs 9) and hit 4AAAA (12-card 16); now do you hit that?

It's easier coding to look at all possible hands, so while it's impractical to ever have 21 Aces (as one would have had to go via 11 Aces), there aren't that many large hands to worry about. The logic I used was start at 21 Aces, see whether by taking any cards any hands were 21 or less (obviously none are, so they all have an EV=-1), and decide to stand. Similarly with 20 Aces of 19 Aces and a Two. At some stage you do hit some hands and that's where you worry about the chances of getting different draw cards and adding up the EVs * pr(card drawn) to get the Hit EV. You need to ignore any totals>21 but look-up the other EVs. You then remember/set the best EV as the hit one.

fyi I got there were 6165 different hands, 187 were 13-cards or more, 284 were 12-cards or more, 422 were 11-cards or more. I can see the logic that many of these hands are probably impossible to get to, but on one project I had to look at the effect of trying to get to 21 for bonus payments. Hence it was easier to let the logic calculate what to do.

Interesting.

I'm trying to think of a 12 card hand other than AAAAAAAAAAAA that doesn't bust. (edit: got it)

I suppose, for completeness' sake, I can think of a hypothetical individual who would take that tenth hit card, because they just know the gift shop strategy card doesn't have his best interests in mind.

Quote: Mirage

I'd check out the Wizard's video (I can't post links) on how to do it in Excel and then just implement this in your language of choice; it isn't harder than it looks to adapt it to finite decks. I got it working in less than a day.

link to original post

Interesting! For a finite deck game, can you use Excel to calculate the basic strategy? It’s not clear if you got it working in Excel or other programs.