I think I found a serious flaw in most Counting Systems

[Skyler62]

Am I Right or Am I Wrong?

https://www.blackjacktheforum.com/sh...rom-Peek/page3

I made a post in the Software forum (link above) in which I said that I think I have discovered a very serious flaw in the way that many of the greatest authors and experts in the world of Blackjack count cards and use those counts to adjust their strategy and wagers. I must admit the odds that I'm correct about this would appear to be pretty low. After all, who am I to dispute the findings made by all these geniuses who have devoted so much of their lives to the game. People like Thorpe, Braun, Einstein and others?

But please let me tell you. For the longest time now, when I've been playing for money, I get a high True Count (like +6) and bet big expecting to win. But I just lose so often that I have been thinking something must be wrong. So, I wrote my own simulation and in so doing, I discovered a little flaw that turns out to mean I'm losing a lot of money because of a serious flaw in the Counting Systems I've tried. I'm going to show you what I mean. I sure do hope I'm not wrong.

I discovered this supposed "serious flaw" while I was creating my own BJ simulation and this is why I think it's so important for people to either create their own sims or at least to be able to examine the source code used to create the sims they use so they can understand exactly how it works. I pledge that if and when I release my BJ sim, it will absolutely be "open source".

I'd like to explain why I consider this flaw to be so serious. Unfortunately, I'm very worried that I'm the one who has made the "serious flaw" and I will wind up looking foolish.

The flaw concerns Counting Systems. One of the most common system was proposed by Braun and the details can be found in The World's Greatest Blackjack Book on page 207. In his system, the cards count as follows: 2-6 are +1, T-K and A are -1 and 7-9 count are zero. Most every BJ player who counts cards should be familiar with this system.

For the remainder of this post, I will use the following abbreviations: RC (Running Count) TC (True Count)

Most every well known BJ author and expert explains how to use these values to compute the RC as well as the TC. I will assume that everyone here understands how to compute TC.

All the authors explain that when TC (True Count) is a specific value (let's say +6), that means the player should alter their strategy and their wagering in a specific way. My problem is that all these authors have everyone believing that a TC of +6 means the cards will behave in a specific way and they will always behave in the same way just as long as the TC remains +6. I think that is terribly flawed.

A TC of +6 does not always mean the same thing. The shoe can have a TC of +6 but it can be in very different states. The odds that you will be dealt a high card or a low card can be very different even though the TC remains +6. Allow me to demonstrate:

Suppose you are the only player at a two deck table. In the following chart, there are always 52 cards remaining in the shoe. Therefore the TC is computed to be the same as the RC. In the following chart, the RC is always +3 and the TC is always +3 as well. Just look at all the different states that can mean and all the different odds that exist for you to be dealt a high card or low card:

(Thank you ZenMaster_Flash for finding my error here and correcting it so both counts are +3).

In a single deck, there are 3 zero cards in each suit (7-9) and so there are 12 of them in the deck and 24 in the two-deck shoe.
There are 5 high cards in each suit (T-K and A) and so there are 20 in the deck and 40 in the two-deck shoe.
Likewise, there are 20 low cards in the deck (2-6) and 40 in the shoe.
So, when the RC (Running Count) is +3, the shoe can be in any one of the following 11 states:

The following 11 cases are the only cases in which you can have an RC of +3 in a two deck shoe with half the shoe (52 cards) remaining. You can have a RC +3 under any of the 11 following conditions.
But, just remember this. The number of zero cards in the shoe can not exceed 24. Likewise, the number of high cards cannot exceed 40 and the number of low cards cannot exceed 40. OK. Here we go:

Zero High Low RC TC Odds of High Card
1 27 24 +3 +3 27/52 = 0.52
3 26 23 +3 +3 26/52 = 0.50
5 25 22 +3 +3 25/52 = 0.48
7 24 21 +3 +3 24/52 = 0.46
9 23 20 +3 +3 23/52 = 0.44
11 22 19 +3 +3 22/52 = 0.42
13 21 18 +3 +3 21/52 = 0.40
15 20 17 +3 +3 20/52 = 0.38
17 19 16 +3 +3 19/52 = 0.37
19 18 15 +3 +3 18/52 = 0.35
21 17 14 +3 +3 17/52 = 0.33

Remember in a two deck shoe there are a max of 24 zero cards, 40 high cards and 40 low cards. In each of the above cases, there are 52 cards remaining in the shoe and the RC is +3 and the TC is +3.
In the 1st case. There is one zero card, 27 high cards and 24 low cards. The total is 52 cards. There are three more high cards than low cards which means the RC is +3.
In the 2nd case. There are 3 zero cards, 26 high cards and 23 low cards. The total is 52 cards. There are three more high cards than low cards which means the RC is +3.
In the 11th case. There are 21 zero cards, 17 high cards and 14 low cards. The total is 52 cards. There are three more high cards than low cards which means the RC is +3.
In all these cases since there are 52 cards remaining out of the original 104, that means the TC is the same as the RC.

But, now look at the odds you will be dealt a high card:
In the 1st case, there are 27 high cards out of a total of 52 total cards. That means the odds are 27/52 or 52% your next card will be a high card.
In the 2nd case, there are 26 high cards out of a total of 52 total cards. That means the odds are 26/52 or 50% your next card will be a high card.
In the 11th case, there are 17 high cards out of a total of 52 total cards. That means the odds are 17/52 or 33% your next card will be a high card.

Do you see the flaw? Even though the TC remains at +3 for all 11 cases, the odds of being dealt a high card vary from 33% to 52%. 33 is only 60% as much as 52. So that is a very large difference.
--------------------------------------------------------------------------------
Would you like to see how this applies to a single deck game? The following chart pertains to a single-deck game in which exactly one half the deck has been dealt and 26 cards remain.
In the following 6 cases the RC is always +3 and the TC is always +6.

Zero High Low RC TC Odds of High Card
1 14 11 +3 +6 14/26 = 0.54
3 13 10 +3 +6 13/26 = 0.50
5 12 9 +3 +6 12/26 = 0.46
7 11 8 +3 +6 11/26 = 0.42
9 10 7 +3 +6 10/26 = 0.38
11 9 6 +3 +6 9/26 = 0.35

Remember in a single deck game, there are a max of 12 zero cards, 20 high cards and 20 low cards. In each of the above cases, there are 26 cards remaining and the RC is +3 and the TC is +6.
In the 1st case. There is one zero card, 14 high cards and 11 low cards. The total is 26 cards. There are three more high cards than low cards which means the RC is +3.
In the 2nd case. There are 3 zero cards, 13 high cards and 10 low cards. The total is 26 cards. There are three more high cards than low cards which means the RC is +3.
In the 11th case. There are 11 zero cards, 9 high cards and 6 low cards. The total is 26 cards. There are three more high cards than low cards which means the RC is +3.
In all these cases since there are 26 cards remaining out of the original 52, that means the TC is computes as double the RC.

But, now look at the odds you will be dealt a high card:
In the 1st case, there are 14 high cards out of a total of 26 total cards. That means the odds are 14/26 or 54% your next card will be a high card.
In the 2nd case, there are 13 high cards out of a total of 26 total cards. That means the odds are 13/26 or 50% your next card will be a high card.
In the 11th case, there are 9 high cards out of a total of 26 total cards. That means the odds are 9/26 or 35% your next card will be a high card.

Do you see the flaw? Even though the TC remains at +6 for all 6 cases, the odds of being dealt a high card vary from 35% to 54%. 35 is only 64% as much as 54. So that is a very large difference.

I have put a lot of work into this post. I sure do hope that I won't come away looking like a fool.

P.S. I think I should explain one of the reasons why I consider this to be such a serious flaw is because if the odds can vary so wildly that your next card dealt will be a high card or a low card, then it would be highly suspect that you should alter the Basic Strategy based on the TC. Most authors have a table that shows when the TC exceeds a certain value, you should Stand instead of Hit or vice versa. Also they show you should change the way you Double or Spllit based on the TC. My point is that since the odds swing so greatly that you will be dealt a high card or low card, it's really not very wise to base these kinds of decisions strictly on the TC. After all, if you hit instead of stand, I think you expect not to be dealt a high card since you will be more likely to bust. I think before changing the decision as to what Action to do (whether you Stand, Hit, Double or Split), you really need to know what the odds are that you will be dealt a high card or low card and as I have shown in the above charts that is MOST DEFINITELY NOT THE SAME AS THE TRUE COUNT! The high swings in the odds of being dealt a high card next make the TC a bad way to make those decisions.

[Frank Galvin]

A forum user destined to challenge Tthree for depth and length of posts. And please understand, that is not necessarily a bad thing.

It appears that you are simply demonstrating that RCs and TCs are not just simple points that travel along a linear path, but rather, can be amongst a wide array of points that can be averaged (may not be the optimal term, but I suspect my point is sufficiently clear) to a point on a line (RC or TC).

[Norm]

Card counting strategies are not perfect play. The strategy you are talking about, Hi-Lo, has a playing efficiency of 0.51, 1.00 meaning perfect. 0.7 is about as high as you are going to get with counting. You can improve this with higher level strategies or side counts (and will find all too many posts here about such). CC is meant to give a human an edge with a reasonable amount of effort. It's not designed for use by computers.

[ZenMaster_Flash]

TC is computed to be double the RC.

Fatal Flaw:

With 52 cards remaining RC = TC

[Skyler62]

ZenMaster_Flash,

You are quite correct. Thank you for pointing out my error. However, I don't think that means any very serious changes to my point.

As a result of some of the posts made here, I now understand that people don't find there to be a serious problem with using the Count Systems the way they do and the way I expected they would.

I especially appreciated the following remarks very much:

Card counting strategies are not perfect play.
......
CC is meant to give a human an edge with a reasonable amount of effort. It's not designed for use by computers.

-----------------------------------------

This was an excellent learning experience for me however and ... I'd now like to ask the members of this forum something else.

I am currently enhancing and revamping my simulation. It has many of the same features as the CVCX simulation. But I'd like to make mine available as "feeware" for several reasons.

I'd very much like to make it Open Source so that I might be able to collaborate with people who may have some experience writing software and know BJ.

Would anyone here be interested in following along with my development of my new version? In exchange for your collaboration I would be happy to provide you with my program source code and my notes which contain much of the reasoning as to why I designed my sim in the way that I did.

If anyone is interested in collaborating or just posting their thoughts if I post some of my code, please let me know?

I'd like to know if you might be interested in collaborating and if so, whether you have any ideas as to how a sim should be run. I have several ideas about the current sims that I've seen. I think they can be improved in several ways and I'd very much like to discuss just how a sim should be organized.

Thanks.

[Norm]

I have several ideas about the current sims that I've seen. I think they can be improved in several ways and I'd very much like to discuss just how a sim should be organized.

Of course I'd be interested in your comments along such lines. Also, I think you should look at CVData, which has vastly more functionality and data than CVCX. You might also want to spend some time reading, starting with Theory of Blackjack written in 1979, which would have explained why this isn't a flaw.

[Skyler62]

KC,

Thank you so much for your input. I regret that I'm currently concentrating on completing my software project. But I will make the effort to review your results and hope to get back to you about it shortly.

[Skyler62]

ZenMaster_Flash,

Thanks again for identifying my error in calculating the TC. I have edited my post and corrected the error.

I'm glad that even though I made that error, it did not change my basic point that even when the counts remain a constant value, other factors can change a great deal.

The one factor that got me all excited was the odds that you will be dealt a high card or a low card.

I just flipped out when I saw the odds of being dealt a high card can be as low as 30% or as high as 50% - even though the TC remains constant all the while.

These authors all recommend you should adjust the strategy tables as to when you Stand, Hit, Double, Split or Surrender depending on the TC. But if the odds you will be dealt a high or low card change so much - even when the Count remains the same, surely it can't be a very reliable factor to determine your Actions (when you should Hit or Stand, etc.)

But thanks to all the good comments in this thread, I now understand this is just a compromise. Because keeping exact counts is just too complex for the human brain, we must find a way to use a count we can handle and use it as best we can. So long as it produces a winning result, that is good enough.

I thank you all very much for your great comments.

[ZenMaster_Flash]

Can you please re-address your original
thesis re: permutations of possible hands ?

To me, not only have you noted nothing
of value, but it is getting "long in the tooth."

[Frank Galvin]

Would anyone here be interested in following along with my development of my new version? In exchange for your collaboration I would be happy to provide you with my program source code and my notes which contain much of the reasoning as to why I designed my sim in the way that I did.

If anyone is interested in collaborating or just posting their thoughts if I post some of my code, please let me know?

Skylar62,

Although my programming skills have fallen off the deep end (college ended in the mid-80s, and never used computer programming skills for work, being an attorney), I would fully appreciate the opportunity to "audit" the collaborative efforts, and perhaps gain an updated understanding of programming (doubt many programmers use fortran, cobol, basic or assembly language any more) as your software simulation program evolves.

Thanks for participating on this website's forum so far, and look forward to your future contributions,

Frank

[Skyler62]

Norm,

Although most simulations can work through millions or billions of rounds without taking so long they are untenable, it's a different story when you want to use them to find the answer to a specific problem such as:

When should I Hit and when should I Stand when I hold T,6 vs Dlr's 6 and the TC is +2? Also, how much should I wager in terms of my original wager. The answer should be given in terms of the range of the count. For example, it has to find that you need to Hit if the count is above 5 and stand if it's below 2 and if doubling is allowed, you should double when the count is between 2 and 5. I'm just trying to paint a picture of what's requred and I hope you get my meaning. The amount of processing required is monumental when you attempt to answer these kinds of questions over all card combinations and all values for the count.

I have written a full BJ simulation and have experience working with it. It was probably the most interesting project I ever produced.

To answer these kinds of questions, it takes much much longer and I think most people would try to find the answer for a single specific card holding for both player and dealer as well as a single count.

To answer this question for all card combinations over all possible counts still requires a huge amount of processing time.

I've never seen how other sims handle some of the processes that can be time consuming - such as shuffling or "fixing" the shoe so that all hands played will be played with the fixed count.

But I have developed some very fast algorithms for several of these processes.

For example my software takes 3 seconds to shuffle a shoe containing 6 decks ten million times.

The problem with running the kind of problem I've outlined above is that you want to play millions or billions of rounds for each question and it's much more time consuming that just playing a normal round. Why?

Because you have to "back up" for every round and "fix" the deck to contain the count you want. Then the next round has to be run assuming the players will Stand. Then the shoe has to be backed up and "fixed" again for the next action - namely assuming the players will Hit. Then again for Doubles (if applicable) and again for Splits (if applicable) and again for Surrender, etc.

The processing time to do this sort of thing is far greater than it is for running a sim where the cards are played straight through without ever "backing up".

In order to produce some software capable of answering these questions in a reasonable amount of time, it has to be designed in a highly efficient manner and from the get-go it has to be designed to do these kinds of things. It sounds to me as if you can use some of these existing simulations to get the answers you want. But you need to adjust things to handle a specific question. I suspect that if you try to answer these kinds of questions for every conceivable card combination and every conceivable count, it will just take too long. But I suppose I can't really be certain until I try it.

My guess is that the process has to be designed to do these kinds of things right from the beginning.

[Norm]

Although most simulations can work through millions or billions of rounds without taking so long they are untenable, it's a different story when you want to use them to find the answer to a specific problem such as:

When should I Hit and when should I Stand when I hold T,6 vs Dlr's 6 and the TC is +2? Also, how much should I wager in terms of my original wager.

Yes, index generation or basic strategy generation are completely, totally different processes than simulation. Also, far more difficult to code. This is handled by CVIndex, which is a part of CVData, and also handles things like hole-carding, partial hole-carding, next-carding, and partial next carding which are interesting problems.

I've never seen how other sims handle some of the processes that can be time consuming - such as shuffling or "fixing" the shoe so that all hands played will be played with the fixed count.

Shuffling is easy. Fixing the shoe, in general, shouldn't be done. CVData runs around 33 million hands a second on my PC, which is a pretty fast PC.

In order to produce some software capable of answering these questions in a reasonable amount of time, it has to be designed in a highly efficient manner and from the get-go it has to be designed to do these kinds of things. It sounds to me as if you can use some of these existing simulations to get the answers you want. But you need to adjust things to handle a specific question. I suspect that if you try to answer these kinds of questions for every conceivable card combination and every conceivable count, it will just take too long. But I suppose I can't really be certain until I try it.

Yes, the software has to be designed for the problem in advance. Optimal betting calculations take several hundred thousand calcs. But, this appears instantaneous on a modern PC. Once the sims are run, with CVCX, you can change the options (say the penetration one card at a time), and the optimal bets are recalculated instantly. Basic Strategy generation is fairly quick, about four seconds per type of hand. Index generation for counting systems takes far longer, depending upon the accuracy desired. For very high accuracy with a multi-level count and a very large number of indices, it can take hours -- longer on a slow PC.

[Skyler62]

Freightman,

Your post helped me remember that Fortran has a "DO" statement which is used to do looping.

Ahh. Those were the good old days.