When writing a program to calculate EV of a given decision in Blackjack, is it possible to do it algebraically or is brute force the only way to ensure accuracy?

Context:

I wrote a program in Python to calculate decision EV for any hand total/true count to find index plays for any given rule set. I know my results are slightly inaccurate because I took some short cuts in my approach to keep the program running quickly. I know this information is widely available and solved for, this was mostly an exercise for myself to get better at Python.

My approach is for any given player hand total (not combination) I look at the probability of them drawing a certain card and the subsequent EV. Example for hitting a 20 vs a dealer's 21:

To generate various true counts, I randomly remove high or low cards from the shoe, recalculate the probability of the outcomes for each hand, then generate the player decision EVs as normal. Repeat this ~100 times for non-zero TCs (to account for variance of removed cards), then take the average EV of each decision. This works pretty well for 6/8 deck games but starts to break down for DD/SD games.

The benefits to this algebraic approach are the speed at which the program runs since there's almost no looping. The problems are pretty obvious intuitively and in my output (below).

E.g. my 12v2 DD index is showing as +6 when it should be +3 since I'm not accounting for the fact that a 12v2 hand will often be comprised 2-3 low cards for the player and the single 2 for the dealer which would raise the TC 1-2 points in a DD game.

So back to my original question - is there an algebraic way to solve for SD/DD indices or is brute forcing through all hand possibilities the only truly accurate method?

Your main problem may be that you are only doing each one 100 times, so the variance between the expected and actual results is larger than what you want. Try 10,000 results (and even then, that's a little low) and see what happens.

If your strategy does not change (other than how much you bet) based on the EV, then what I would do is this:

1. Start with a full deck/shoe, and a running count and TC of zero

2. Play hands through the shoe, keeping track of the player total, dealer up card, and TC at the start of the hand, and recalculating the TC after the hand is played

3. Remember to take into account when the deck/shoe will be reshuffled

4. Repeat 1 and 2 as many times as you can - anything short of 100,000 is not going to be accurate, and I would prefer millions of runs.

Also I'm trying to calculate the EV of each decision, not just the optimal decision. In your approach above would the program just randomly pick hit/stand/double/split/surrender for each hand?

Quote:DonutsAlgebraically meaning I don't simulate each hand I just look at the probability of each outcome and the EV of that outcome for a specific hand. For clarity, each hand's EV is calculated once per decision and each TC is what's being simulated 100 times. Since I'm only removing a handful of cards from the shoe I'm not sure I need more than that to get pretty accurate results.

Also I'm trying to calculate the EV of each decision, not just the optimal decision. In your approach above would the program just randomly pick hit/stand/double/split/surrender for each hand?

link to original post

I would use basic strategy.

And even if you were simulating something like a coin toss, I would use far more than 100 results.

Looking at (say) 93 vs 2, then you need to work out the EVs of 93 vs 2 (standing) then 93A,932,933...939 (obviously 93X is a loser, so you set that to -1). In theory you need to look at whether you hit 93A using a similar technique.

Once you've coded 93 v 2 you can do any other player hand.

Quote:Donuts<snip>My approach is for any given player hand total (not combination) I look at the probability of them drawing a certain card and the subsequent EV. Example for hitting a 20 vs a dealer's 21:

<snip>link to original post

Donuts,

I am puzzled by this example of yours: if the dealer already has 21 before the player acts, then the dealer has a BJ. Why isn't the hand over before the player acts?

Dog Hand

Quote:gordonm888Your algebraic approach is what is usually called "combination mathematics." Most blackjack calculators and many analyses are based on combination math. Most of us do take into account the composition of the dealer's hand. It is sometimes important: say, for 12v4. A T-2 vs 4 is often played differently than a 9-3 vs 4,

link to original post

Is the right approach then to do what I did but instead of just using dealer/player totals use explicit two card hand combinations (e.g. 2 + 10 and 3 + 9 instead of just 12) then calculate the weight of each combination to decide what to do on the average 12?

Quote:DogHandQuote:Donuts<snip>My approach is for any given player hand total (not combination) I look at the probability of them drawing a certain card and the subsequent EV. Example for hitting a 20 vs a dealer's 21:

<snip>link to original post

Donuts,

I am puzzled by this example of yours: if the dealer already has 21 before the player acts, then the dealer has a BJ. Why isn't the hand over before the player acts?

Dog Hand

link to original post

Bad example from me might have been better to do a dealer 20 with a 1,0,-1... etc. chart instead

No - for instance the decision of 10 2 vs 4 single deck is to hit, whereas 9 3 vs 4 is to stand. A more extreme case is 7 7 vs Ten, where you stand.Quote:Donuts...Is the right approach then to do what I did but instead of just using dealer/player totals use explicit two card hand combinations (e.g. 2 + 10 and 3 + 9 instead of just 12) then calculate the weight of each combination to decide what to do on the average 12?...

With infinite decks it doesn't matter how your total is made up, with with finite decks sometimes which cards are in your hand makes a difference.

Of course if you're trying to develop a count method and when you should change from basic strategy, then you possibly need to take shortcuts, otherwise it will be too much to remember.

Quote:charliepatrickNo - for instance the decision of 10 2 vs 4 single deck is to hit, whereas 9 3 vs 4 is to stand. A more extreme case is 7 7 vs Ten, where you stand.Quote:Donuts...Is the right approach then to do what I did but instead of just using dealer/player totals use explicit two card hand combinations (e.g. 2 + 10 and 3 + 9 instead of just 12) then calculate the weight of each combination to decide what to do on the average 12?...

With infinite decks it doesn't matter how your total is made up, with with finite decks sometimes which cards are in your hand makes a difference.

Of course if you're trying to develop a count method and when you should change from basic strategy, then you possibly need to take shortcuts, otherwise it will be too much to remember.

link to original post

That makes sense - I don't think I'd ever bother learning composition dependent basic strategy since SD games are a bit rarer these days anyway. If I was just going to do this exercise for DD/6D would the weighted average method I mentioned work then?