A small dilema.

Rather than deal random hands, it might be better to loop through every possible starting hand (or total) and play each one out the same number of times.

 

Methodology

The timing of this comment is good. I've been meaning to post about the differences in how my software works compared to more traditional methods of generating strategies and computing various probabilities.

As Coliin points out, one could exhaustively go through every hand (or hand total) and perform whatever calculation one is interested in. Many useful computations can be done this way and, as I understand it, most basic strategies are computed in this this way.

A fundamental problem with this is the composition of the deck against which one performs the calcuations. One is generally forced to assume that the hands are dealt from the top of the deck (or shoe), which is convenient, but only useful for analysing situations in which the deck is shuffled after each hand. Playing online if the only situation I am aware of where this happens for real.

We can take a further suggestion from Colin's comment and simulate each enumerated hand an equal number of times. Once again the composition of the deck is an issue. One can not simply deal the same hand over and over again from a simulated deck, because the nature of the hand in question could soon create a bias in the composition of the deck (e.g. you're analysing a hand which is a pair of 10's). One is once again forced to assume that each hand in question has been dealt from the top of the deck. Also, in real life, one is never dealt the same hand over and over again.

Deck composition can be elimited as a factor by assuming infinite decks, which simplifies the calculations but is not in any way a real world model. Exact deck omposition is also an example of information that is not useful to us as humans. What we would like to know is what should we do in a given situation across a variety of possible deck compositions.

Exhaustive approaches can also be computationally vast and sometimes infeasible.

Anyone who knows how random numbers are generated in computer programs knows that it is almost impossible to generate an actually random stream of numbers, cards, dice throws, etc. Cards are not actually random anyway. They are affected by the way the cards are dealt, played, collected and shuffled (e.g. did you know that the player at 1st base gets fewer blackjacks than the other players at tables with 2 or more players?).

So how do I deal with all of this?

What my software tries to do is to answer the question of what is the result of applying strategy X in situation Y averaged out over the various states in which the situation might arise with the information available (and useful) to a human player. The only way (that I know of) to discover that is to simulate exactly what it is that we, as human players, do when we're playing a tournament or grinding it out at the tables. That is to simulate an actual shoe of cards being dealt, acted on, collected and reshuffled in the same manner as in a live casino.

This approach has the property that it automatically accounts for any subtleties introduced into the process by the way the cards are dealt and handled. Each time a particular hand is dealt, it is dealt with the deck in a variety of states which could actually arise as the game is played and never in a state which could not occur.

With a larger number of decks, this often has no bearing on the result. With a smaller number of decks (<= 6) there are often observable differences.

The main disadvantage of this approach is, as we have observed, statistics for rare situations are slow to accumulate. So if you want the exact percentage results for every possible hand, the computattion will take longer than the exhaustive approach.

The main advantage of this approach, is that the big picture emerges quickly. For hand strategy generation, the contribution of the most common situations accumulates quickly and after relatively few iterations, the decision of should I hit/stand/double/split for a particular hand becomes clear. If the decision is close, then more iterations are in order. If you want exact percentages, then even more iterations are in order On the other hand, the contributions of situations which rarely (or never) occur and which contribute little to the bottom line expend correspondlingly fewer cpu cycles, making the overall computation faster.

In our example here, where the question was "What would the win/lose/push percentages be for various hands if I were to play a 'must not lose' strategy with 6 decks in real life without knowing the exact composition of the deck", my method seems appropriate. The overall contribution of a hand which occurs 11 times in 2 billion trials is likely beyond the range of floating point computation accuracy. After only 11 samples, the result of (18.2/81.8/ 0.0) is not all that close to the (20/80/0) expected by BlueLight, however, for the purposes of analysing this teaser, would this difference have been of any value to us? Would we have even considered doubling a hard 4 in a "must not lose" situation or factor in that our opponent might do so in a 17 19(doubled) 17 4 situation? This is another example of information that is not useful to us as humans.

Having said all that, please be assured that when I post a percentage result for a particular hand or situation, I make sure that sufficient trials for that situation have occurred.

Also having said all that, the number of trials for each hand in my hand result tables would be a useful addition, so that one can assess the accuracy and importance of the result for for each hand. I think I'll do just that!

 

Just to be clear, combinatorial analysis (which is how basic strategy EV computation is usually done) is radically different from simulation. The entire tree of all possible hands is generated. The calculation is therefore, in principle, exact. It involves the combination of the various abstract probabilities, rather than the aggregation of actual results from some number of repeated trials.

There are a couple of caveats to this, though. One is that the algorithm for handling splits is notoriously tricky. My understanding of the subject is a bit limited, although its something I've looked into from time to time, and even got into discussions about on Ken's now-defunct blackjackinfo.com forums. But the bottom line seems to be that different programs may yield slightly different split EVs, either due to deliberate approximation techniques (to speed up the processing), or due to differences of approach (or of course bugs).

As I said in an earlier post, I has the idea of modifying a CA program to generate win/push/loss probabilites, rather than hand EVs. (The code which I have been looking at discards intermediate probabilities once they have been used to create the corresponding EVs.) The difficulty in handling the splits is one of the things that put me off!

The other caveat is the cut-card effect, which means that CA-calculated results don't quite match the reality of a shoe game dealt with a cut card (but do match a CSM, or any game in which the number of rounds to be dealt is not determined by a cut card).


But what I was actually suggesting in my previous post is a sort of hybrid approach, a simulation in which the same starting hand is repeatedly played.

As I understand it (which is poorly), it is only the cut-card effect that makes off-the-top analysis in any way invalid. Without that, the EV off the top is the same as the average EV at any level of penetration in the deck.

So if you have no knowledge of the deck composition (i.e. you are not counting cards) then the EV at any point is the same as the EV off the top.

I'm not sure that there would be any problem in repeatedly dealing cards to the same starting hand from a diminishing deck, until a virtual cut-card is reached and a shuffle takes place.

It's true that this would generate a few 'impossible' deck compositions. E.g., if one card is drawn to the hand before standing, then on the second playing of the same hand we have a deck that has been depleted by just one card. But then that can be the case in real life if there is a burn card, and we wouldn't expect to have to simulate scenarios of different numbers of burn cards separately from the general case. And think of all the compositions that could or could not happen depending on the number of other players at the table.

My intuitive, non-mathematician's assumption is that all the different impossible cases balance each other out, giving a zero overall net effect. Possibly there is actually a mathematical proof of this.

That sounds like a good idea. And despite all the points I rasied above, I do agree that a big benefit of a 'real-life' simulation is that it automatically caters for all the subtle effects that we can (or more importantly can't) think of.

It might be useful, though, to be able to test one specific hand in isolation. If that's the only cased you are interested in, then it's a shame to have to wait for the simulation to randomly stumble upon it a sufficient number of times.

Oh, and thanks very much for making your results available to us!

 

2+2 vs dealer A or 9

The probability of not losing with 2+2 against dealer A with iinfinite deck is:

Dealer standing totals H17 S18 up card A
Player standing totals H17 S19 cards 2+2

Advantage.....Prob WIN.....Prob PUSH.......Prob LOSE

..-0.2922.........0.3058........0.0961............0.5981

These are figures for playing basic strategy. If the player soft standing total is changed to S18, then the following is obtained.

..-0.2931.........0.3049........0.0970.............0.5980

Note that by standing on soft 18 (not as basic strategy says) we lose a tiny less often, however we win less often bringing the total EV (Pr Win - Pr Lose)
down compared to the basic strategy (S19) play.

These figures are based on every possible drawing possible drawing permutation, outcome and its corresponding probability for the player and dealer.

For six decks I can't get real accurate numbers because of the "Peek Effect" (when the dealer has an A or 10 up) effects the probabilities of the player's cards drawn.


For a six deck game when the dealer has a 9 up and the player has 2+2

Dealer standing totals H17 S18 up card 9
Player standing totals H17 S19 cards 2+2

Advantage.....Prob WIN.....Prob PUSH.......Prob LOSE

..-0.2378........0.3341.........0.0940............0.5719


Splitting pairs when you need to avoid a loss can be tricky.

If the dealer has a 9 up and the 1st hand ends up with hard 18 and you reach hard 18 on the second hand it might be better to hit rather than stand. You can afford to bust if the 1st 18 wins; if the 1st 18 doesn't win then hitting hard 18 on the 2nd hand gives the player an extra shot.

If the dealer has a 5 up and the player splits it might be worth while to a low stiff say 13 on the 1st hand.

This splitting situation where you need to break even can be crazy.


.................................BlueLight

 

Your points are all well taken and I agree with most of them (exceptions noted below). I guess my overall reason for preferring real-process simulation is that it results in a simpler algorithm which automatically accounts for all of the intangibles. These factors make it more likely that the computation will be correct (bug free) and make it more likely that I will get a correct answer to the question "what is likely to happen if I do this for real".

I must disagree here. The effect is real and S. Yama and I observed it while working on a problem together. The example I gave previously (analysing how to play a pair of 10s) makes it easy to see one particular kind of bias. If you repeatedly deal pairs of 10s from a diminishing deck, it doesn't take long before the diminished deck is very depleted in that regard. If you're a card counter, the alarm bells are already ringing in your head!

The example that S. Yama and I were analysing was a tournament situation in which a win of a certain amount would guarantee advancement over another player. As a test, I modelled it in 2 ways, hoping to get the same result:

1. A single player model with the goal to win X
2. A two player tournament model in which winning X would guarantee advancement

I (unwisely) decided to model situation 2 such that the second player had blackjack, in order to guarantee his result. The result was that player 2 was dealt a 10 and and ace on every hand of a diminishing deck. The generated strategies ended up being identical, however simulating them yielded different results. While going over the output, I found the problem. I noticed that when simulating situation 2, player 1 was dealt fewer blackjacks than in situation 1. Since player 2 was getting blackjack on every hand, the diminishing deck became depleted of 10s and aces. Getting blackjack was sufficient for player 1 to advance, so when he recieved fewer than normal, it affected his rate of advancement.

When I changed the program to deal from the top of a new shoe on each iteration and changed things so that dealing a blackjack to player2 did not affect the cards dealt to player 1, the number of black jacks dealt to player 1 was the same for both models and the results for the two models became the same.

Yes, this is very useful and my software can do this. In these cases I now -(see above!) start each iteration with a new shoe in order to avoid inadvertent bias. As you point out, starting from a random position in each shoe would be equivalent. For most cases, the simultor is fast enough that I don't have to use this feature, but as we've seen, it can happen that a particular hand can be exccedingly rare. In thoses cases, I have resorted to simulating hands in isolation in order to get a result.

 

If the computation is for before the dealer peeks, can't you add the probability of a dealer blackjack to the loss column and then compute the win/lose/push rates as usual (assuming the 10 and Ace are gone) and multiply those results by the probability of no dealer blackjack?

If the computation is after the dealer has checked and does not have blackjack (mine were done this way, as requested), then the dealer's hole card is simply another unseen card and can be treated as if there was no hole card (for a proof, see BlackJack Attack chapter 4).

These numbers agree with mine. It's nice to get the same result as another independent computation. Thanks!

 

That's not what I was suggesting. I meant that you would deal the pair of 10s (and dealer upcard) once only, then repeatedly deal the remaining cards from the diminishing deck as you play the hand multiple times.

 

Ahhh -- interesting idea. I may just implement that!