What subtlety of probaboility theory have I missed?

I’m writing a program to calculate the EV for various hands in Blackjack.

I’ve checked my results against the tables at the usually reliable Wizard Of Odds

In most cases I calculate exactly the same values they do, except in a few cases. These cases being where the dealer has an ace or a ten showing. In such cases my program will *always *calculate a result slightly different to WOO’s, and as far as I can tell, this is the only occasion it ever does so.

The difference is only slight. For example, given a 6 deck shoe, stand on soft 17, dealer shows a ten, player has A8 the odds are:



            WOO             Mine
 stand  +0.063321 	 0.064313 
   hit  -0.087616        0.086395
double  -0.233592 	 0.226191


My program uses a recursive algorithm. At each loop, the program considers in turn every card that might be drawn next, the chance of drawing that card, and the EV for that card:



total EV =
   chance of ace     *  EV for ace      +
   chance of two     *  EV for two      +
   chance of three   *  EV for three    +
...


The calculation of the EV for each card appears to work correctly.
After long consideration of the matter, I think the error must lie in the calculation of the chance of drawing a particular card. This will be slightly different depending if the dealer has an ace or ten showing. And this is the only difference between the ones I’m getting right, and those I’m getting wrong.

Note that I’m assuming the dealer has checked for Blackjack, and hasn’t got it. Thus if the dealer shows a ten, the hole card cannot be an ace, and vice-versa. So, for example, assuming a single deck, player has stood on 4,8,6, dealer shows a ten, I figure that there are 44 possible cards the dealer might have for the hole card.



Chance of an ace =   0
chance of a  2   =   4 in 44
chance of a  3   =   4 in 44
chance of a  4   =   3 in 44
chance of a  5   =   4 in 44
chance of a  6   =   3 in 44
chance of a  7   =   4 in 44
chance of a  8   =   3 in 44
chance of a  9   =   4 in 44
chance of a 10   =  15 in 44


The above is the logic I’m using at the moment, but it appears to give incorrect results.

Here’s the section of the program

In the following, cards_in_deck is a structure that holds information about the cards not in play and still in the shoe, available to be dealt.

cards_in_deck.cards_remaining is an integer showing the total number of cards left
cards_in_deck.Ace is an integer showing the number of Aces left




        If dealer_hand = "A" And dealer_checks_for_blackjack Then
            '----------------------------------------------
            ' This code operates only if dealer has a single 
            ' ACE showing, and checks for Blackjack. We know 
            ' the hole card cannot be a TEN, so the chance of 
            ' any other card increases.
            '----------------------------------------------

            search_type = "ace_showing"
            number_of_cards = cards_in_deck.cards_remaining - cards_in_deck.ten
            chance_of_ace = cards_in_deck.Ace / number_of_cards
            chance_of_ten = 0

        ElseIf dealer_hand = "X" And dealer_checks_for_blackjack Then
            '----------------------------------------------
            ' This code operates only if dealer has a single 
            ' TEN showing, and checks for Blackjack. We know 
            ' the hole card cannot be an ACE, so the chance of 
            ' any other card increases.
            '----------------------------------------------
            search_type = "ten showing"
            number_of_cards = cards_in_deck.cards_remaining - cards_in_deck.Ace
            chance_of_ace = 0
            chance_of_ten = cards_in_deck.ten / number_of_cards
        Else
            '----------------------------------------------
            ' This code operates in all other situations.
            ' 1) the dealer has a 2-9 showing or
            ' 2) dealer does not check for Blackjack
            ' 3) dealer has already drawn one or more cards.
            '----------------------------------------------
            search_type = "normal"

            number_of_cards = cards_in_deck.cards_remaining
            chance_of_ace = cards_in_deck.Ace / number_of_cards
            chance_of_ten = cards_in_deck.ten / number_of_cards
        End If

        chance_of_two = cards_in_deck.two / number_of_cards
        chance_of_three = cards_in_deck.three / number_of_cards
        chance_of_four = cards_in_deck.four / number_of_cards
        chance_of_five = cards_in_deck.five / number_of_cards
        chance_of_six = cards_in_deck.six / number_of_cards
        chance_of_seven = cards_in_deck.seven / number_of_cards
        chance_of_eight = cards_in_deck.eight / number_of_cards
        chance_of_nine = cards_in_deck.nine / number_of_cards

        ...


So, what am I missing?

All I know about probaboility theory is that the time it takes the pot to boil is inversely proportionate to the time it is watched. If it is watched constantly, the time taken to boil approaches infinity.

Hope that helps!

:smiley:

Have you tried removing this assumption and seeing if you can produce their results?

Yes.

I have an option in my program to decide if the dealer does or does not check for Blackjack. If “does not check” is selected, then it doesn’t use that assumption.

Note, by the way, that the tables at WOO state that dealer has already checked for blackjack.

You show how you treat the checked-for-blackjack situation when considering the dealer’s hole card. Does your recursion tree, which presumably loops over possible cards you or the dealer might receive with a hit, get properly trimmed for this, too?

I believe the dealer doesn’t check for blackjack if they have a 10 showing. They only check if an ace is up.

After review, it looks like the rules depend on the casino. And the WOO states they check for both ace and ten, so I’d assume their odds assume that. And unless you’re considering insurance (which would only reduce the EV), I’m not sure checking the card in advance would change the results anyway. You still win or lose the same, right?

Does your program take into account that a 21 in your hand (non-blackjack) loses to a dealer blackjack, it’s not a push?

Hmmm…My first thought is, how do you model checking for an ace or 10 before executing the code? In the first set of comments to your code, you indicate that you check for blackjack within that code. But then you say that the chance of a 10 is 0 if an ace is showing. But that’s not true in general. There is some nonzero probability that the hole card is a 10. But in your code, it seems that you go ahead and declare “chance of 10” to be 0.

It seems that somehow, you have to take into account that there are cases where you do get a 10 with an ace showing. I don’t see how you’re modeling this.

I’m not sure what you’re asking there.

I’ve never seen a game where that happens. It’s always a push. That apart, if the dealer has blackjack, the game is over immediately. There are no possibilities to calculate.

This code comes after the dealer checking for blackjack. If the dealer has blackjack, it’s game over, and the code never gets to that point.

If the code ever does get to that point, then the dealer has something other than a 10-A combination. If he’s showing an ace, he is concealing something other than a ten.

If the dealer has blackjack, you still have to calculate if the player also has blackjack, in which case it’s a push. You are right that if the player doesn’t have blackjack, the dealer immediately wins.

Maybe it’s that you say you’re using a six-deck shoe, but you’re measuring probabilities out of just 52 cards?

E.g. probability of a 10 should be (16 x 6 - 1) / (52 x 6 - 4) = 95/284

Probaility of non-showing cards is less affected by there being six decks.

Oops, that should be (52 x 6 - 4 x 6 - 4), to get the 284 possible hole cards.

Can you explain the logic of that formula?

6 decks = 52 x 6 cards, of which 4 x 6 are aces, 4 x 4 x 6 are T/J/Q/K, and 4 are visible.

One Ten is visible, so that leaves 4 x 4 x 6 - 1 .

Assume that the hole card cannot be an ace.

So the probability that the hole card is T/J/Q/K = (4 x 4 x 6 - 1) / (52 x 6 - 4 x 6 - 4) = 95/284 .

Wait, in your later example you were using a single deck only. My bad.

When you reach this subroutine are you sure you have already removed the dealer’s up card from cards_in_deck.cards_remaining and from number_of_cards ?

Hard to tell without seeing the rest of the code but I’m thinking something like this:

number_of_cards = (cards_in_deck.cards_remaining -1) - cards_in_deck.ten

and/or

chance_of_ace = (cards_in_deck.Ace -1) / number_of_cards

and/or

chance_of_ace = (cards_in_deck.Ace -1) / (number_of_cards -1)

and the same for the “X” part.

Without pointing finger at a specific piece of code (I’m not sure the fragment you posted would be enough) I have a hunch about the possible nature of the bug, and an approach that would have avoided it. Please understand: I don’t claim that your approach is incorrect; just that an alternate approach would avoid the subtlety that might have led to a bug. (The subtlety is that you have to develop the distributions for Dealer’s hole card and subsequent hits in different ways.)

The way I would approach your problem is to ignore that you know Dealer doesn’t have Blackjack! In other words, don’t forbid Ace as hole card when dealer has Ten, just proceed as you were, but treat blackjack as a special case only at the end.

In other words (and ignoring splits and doubles for simplicity), replace the three outcomes Win, Draw, Lose with four outcomes: Win, Draw, Lose-to-Blackjack, Lose-to-other. The final calculation for the EV numbers you posted would be EV = (Win - Lose-to-other) / (Win + Draw + Lose-to-other)
Simple … but the special casing of Dealer’s hole card is eliminated.