I think I found a serious flaw in most Counting Systems

[Freightman]

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.

Punch cards, oh brother, and to get computer time - oi vey!

[Norm]

Punch cards

5081s. Hey, better than paper tape.

and to get computer time - oi vey!

I lucked out there. When I was 17, Univ. of Penn. offered me a job as a mainframe systems programmer. I got all the free computer time I wanted, including getting a room full of equipment to myself on Sundays.

[k_c]

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 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 double the RC. In the following chart, the RC is always +3 so the TC is always +6. 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:

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 +6 27/52 = 0.52
3 26 23 +3 +6 26/52 = 0.50
5 25 22 +3 +6 25/52 = 0.48
7 24 21 +3 +6 24/52 = 0.46
9 23 20 +3 +6 23/52 = 0.44
11 22 19 +3 +6 22/52 = 0.42
13 21 18 +3 +6 21/52 = 0.40
15 20 17 +3 +6 20/52 = 0.38
17 19 16 +3 +6 19/52 = 0.37
19 18 15 +3 +6 18/52 = 0.35
21 17 14 +3 +6 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 +6.
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 computes as double 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 +6 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.

I haven't posted in a while but maybe I can help you with an answer to this problem.

It is true that a given count in a given counting system can consist of many varying compositions relative to the system as you have pointed out with your example using the HiLo count. We can call each of these counting system compositions a "count subset." However, each of these count subsets are not equally probable to occur. In order to determine the probability of drawing each rank we must first compute the probability of occurence of each subset. I have written a program that does this and I am going to post some sample outputs and hopefully it will shed some light regarding your question.

The following shows what the possible inputs are followed by what is output. I'm sorry that there is so much posted but it is relatively simple to see what is happening in each screen with just a short glance and I wanted to somehow show all that is input. In this case the output shows that for a HiLo running count of 0 with 26 cards remaining to be dealt and no specifically removed cards dealt from 1 deck there are 7 possible count subsets the probability of drawing A,2,3,4,5,6,7,8,9 = 0.0769231 = 1/13, the probability of drawing a ten value card = 0.307692 = 4/13, and the probability the input running count = 0.124165. These probabilities are dependent upon the probabilities of each of the possible subsets. This may not seem remarkable because these are the full shoe probabilities but it turns out that for HiLo the only time the full shoe probabilities occur for less than a full shoe is when the remaining number of cards is exactly a half shoe for any number of decks.

Simply put, the probability of drawing a given rank relative to a given counting system dealt from a given number of decks is dependent upon all of the count subsets and their probabilities. The number of possible count subsets and their probabilities is dependent upon running count and number of cards remaing to be dealt.

Screen 1 - input of count tags and number of decks:

Please input tags relative to what remains in shoe
No input defaults to tag = 0

Example: HiLo tags (1-10) {1,-1,-1,-1,-1,-1,0,0,0,1}
rank: A tag: 1
rank: 2 tag: -1
rank: 3 tag: -1
rank: 4 tag: -1
rank: 5 tag: -1
rank: 6 tag: -1
rank: 7 tag: 0
rank: 8 tag: 0
rank: 9 tag: 0
rank: T tag: 1

Decks (no input defaults to 1 deck): 1


Press any key to continue
************************************************** ************************************************** *************************

Screen 2 - input of optional side counts (skipped in this case)

The count you have entered consists of 3 groups:
1,10 (1) 2,3,4,5,6 (-1) 7,8,9 (0)

Press s or S to input optional side counts.
Press any other key to skip side counts and continue.
Skip side counts.

Press any key to continue
************************************************** ************************************************** *************************

Screen 3 - input of cards remaining, running count, and number of specifically removed ranks (none in this case)

Count tags {1,-1,-1,-1,-1,-1,0,0,0,1}
Decks: 1 (possible input for cards remaining: 1 to 52)
Cards remaining (defaults to previous input; 1/2 shoe if none): 26
Natural initial running count: 0
Running count (no input defaults to 0): 0
No side counts
Number of each rank specifically removed (no input defaults to 0):
A:
2:
3:
4:
5:
6:
7:
8:
9:
T:


Press any key to continue
************************************************** ************************************************** *************************

Screen 5 - Program output for above input (probability of running count, number of count subsets, probability of each rank)

Count tags {1,-1,-1,-1,-1,-1,0,0,0,1}
Decks: 1
Cards remaining: 26
Initial running count (full shoe): 0
Running count: 0
Subgroup removals: None
Specific removals (1 - 10): {0, 0, 0, 0, 0, 0, 0, 0, 0, 0}

....computing, please wait

Number of subsets for above conditions: 7
Prob of running count 0 with above removals from 1 deck: 0.124165

p[1] 0.0769231 p[2] 0.0769231 p[3] 0.0769231 p[4] 0.0769231 p[5] 0.0769231
p[6] 0.0769231 p[7] 0.0769231 p[8] 0.0769231 p[9] 0.0769231 p[10] 0.307692

Press x or X to exit program (it may take some time to close,)
any other key to enter more data for same count tags/decks:

k_c

[Norm]

Thanks KC. What it comes down to is a compromise between difficulty and efficacy. Which is why we have different strategies for people with differing circumstances. And counting is just the beginning.

[Skyler62]

Thank you Norm. I had never even heard of that book before.

I am kind of shocked now that it is referred to as "Generally considered the bible for serious blackjack players".

I currently have the following books. Some of these are much more valuable then others.

BJ BOOKS
Professional - Reference Michael Dalton
BJ Secrets - Stanford Wong
Knock Out BJ - Olaf Vancura & Ken Fuchs
Million Dollar BJ - Ken Uston
Perfect BJ System - Anon
Science of Casino BJ - N. Richard Werthammer
World's Greatest BJ Book - Lance Humble & Carl Cooper


I really enjoy Stanford Wong's book. I often skim through parts of it when I'm too tired to work on my software.

Let me just tell you my primary thought about the sims that I've seen.

They all tend to have only one orientation. They all tend to operate in just one way.

The user specifies a number of parameters. There are a great number of these. I have currently identified about 30. Very diverse kinds of things. But I see this website has a special section devoted to just identifying these parameters. I haven't had time yet. But I intend to visit that section. I am very confused about several of these options that seem to conflict with each other. But I need to stick to working on my software.

Some of them are:
"is DAS permitted",
"how many times may a player split pairs"
"is doubling on 9 permitted?"
"is doubling on T permitted?"
"is doubling on E permitted?"

Once the user specifies the values of all these parameters (as well as the number of rounds they want the sim to run), the sim begins to chug away and after running the specified number, it comes back and gives a result.

But there are so many other possible ways a sim can operate. Let me just specify a few.

Given a specific group of cards for the player and for the dealer and a specific count, find the best Action for each possible hand.
For example: If the player holds a 7,T or A5 or 9,6 and the Dlr has an up card of 7 or 8 and the TC is +3, run two million rounds and produce the results that show for each combination, how much money will be won or lost depending on whether the player Stands, Hits, Doubles, Splits, Surrenders, etc.

I think of this configuration as producing the best Actions to take.

I have a method of setting the count before any hands are played and then playing a round and then resetting the deck to contain that same TC and playing the round again - each time with a different Action. In this way, I can learn the best action to take under any of these circumstances.

Another config is similar except it looks for the best amount to wager under each condition.

Do you see where I'm going? I think these kinds of configs are very possible. But, unfortunately, most people seem to think a sim means just one thing. Run it given a specific count system and wagering system and just see what the result is in terms of money won or money lost.

Once all the hard work is done in producing a sim, it's not that difficult to make it do so many interesting things. It can produce a tremendous wealth of information.

[Norm]

Given a specific group of cards for the player and for the dealer and a specific count, find the best Action for each possible hand.
For example: If the player holds a 7,T or A5 or 9,6 and the Dlr has an up card of 7 or 8 and the TC is +3, run two million rounds and produce the results that show for each combination, how much money will be won or lost depending on whether the player Stands, Hits, Doubles, Splits, Surrenders, etc.

This can be done either with simulation or combinatorial analysis. CVData does this via simulation, with some CA -- but not in the manner that you think as that's too slow. It takes billions of hands that are relevant, which would be trillions in a normal counting sim.

Another config is similar except it looks for the best amount to wager under each condition.

For non-camouflage play, this is done after a sim as per Kelly Criterion. You will note in CVCX, you do not set any betting strategy before a sim. You can change the bets after a sim and instantly see changes in results. Or, change depth, rules, decks, bankroll, desired risk and instantly have it calculate the best bets without rerunning the sim. If you wish to use cover play, that still must be handled via separate sims.

[Skyler62]

Frank,

You may be surprised to find that my college days ended long before yours did. But I have a friend to introduced me to an Object Oriented Programming Language called Delphi and I took to it like a duck to water. I've been using it ever since.

If you have any experience with programming - even using Fortran - you should not have much problem understanding Delphi.

Especially since I have prepared a very brief introduction to Delphi just listing the various data types and programming constructs. They are all pretty straight forward. You will remember the IF statement from FORTRAN and although I can no longer remember, I'm certain FORTRAN has some kind of looping construct.

I doubt you'll have much of a problem. I'm only working on the first draft of my Introduction to Delphi, but I'll post a piece of it here to give you a general idea:


-----------------------------------------------------------------------------------------------------------------------
DELPHI - INTRODUCTION & GENERAL NOTES

Hello. My pen name is Skyler Doombrofsky and several years ago I wrote a Blackjack simulation. I wrote it using the programming language Delphi. I'm currently revising and enhancing this simulation and I want to make it public so that anyone who knows the basics of Delphi will be able to understand how it works and make modifications or improvements.

Shortly after the IBM PC was first produced (around 1981), there were only a small number programming languages available and most of them were either extremely expensive or didn't work very well.

A company called Borland introduced an excellent product called "Turbo Pascal". It was a very small product that had a surprisingly blazingly fast compilation time and produced excellent programs that were very tiny and ran very quickly. It was a programmer's dream. Once Windows was introduced, programming languages needed to be able to handle objects and the market was taken over with Object Oriented Programming Languages. Almost all programming languages used after that were Object Oriented Languages. Borland adapted Turbo Pascal by introducing a product called "Delphi". You can Google Borland, Turbo Pascal and Delphi if you want more information. I will now present a very brief summary of some of the Delphi basics so that you will have a good chance to be able to read and understand my BJ Simulation.

The one thing about Delphi you should know is that it's usually used to produce Windows software with strong visual elements. It's usually designed to run under Windows and operate with menus using a mouse. But I use Delphi in a way that is more like older software. My sim runs from a command line and although it runs under Windows, it's not like most Windows apps. It runs in a Command Window which looks much like the older kinds of programs (the kind that ran in a DOS window). The following are some basic facts about Delphi. I want to begin by defining several common data types of variables.
-----------------------------------------------------------------------------------------------------------------------
DELPHI NUMERIC DATA TYPES

All Delphi variables are defined as being one of several data types. The most common numeric data types are:

Byte - unsigned integer occupies 8 bits. Its range is 0 to 255.
Shortint - signed integer occupies 8 bits. Its range is -128 to +127.
Word - unsigned integer occupies 16 bits. Its range is 0 to 65536.
Smallint - signed integer occupies 16 bits. Its range is -32768 to +32767.

Longword - unsigned integer occupies 32 bits. Its range is 0 to 4,294,967,295.
Integer - signed integer occupies 32 bits. Its range is -2,147,483,648 to 2,147,483,647.
Cardinal - unsigned integer occupies 32 bits. Its range is 0 to 4,294,967,295.
Longint - signed integer occupies 32 bits. Its range is -2,147,483,648 to 2,147,483,647.
Int64 - signed integer occupies 64 bits. Its range is -2^63 to +2^63-1

I prefer to use the Integer & Longword data types and do not use Longint or Cardinal. This is just a personal style choice. There is nothing wrong with using Longint or Cardinal.

Delphi uses two string data types. You can define a string and specify its maximum length as follows:

Name: String[25]; // Name is defined as a string variable with a maximum length of 25 characters.

Alternatively, you can define a string with an unspecified maximum length. These strings have a maximum length of 2,147,483,647 characters.

LongName: String; // LongName is defined as a string with an unspecified maximum lengh. It's maximum lenght is 2,147,483,647 characters.

The cardinal data type seems to be reserved for the largest integer data type that runs under the current version of Delphi. The current version is a 32 bit version. If and when a 64 bit version is made available, I expect the Cardinal data type will occupy 64 bits.

A final comment. IMO, Delphi's string variables are phenomenal. One of their very best features.
-----------------------------------------------------------------------------------------------------------------------
DELPHI ARRAYS

Like most programming languages, Delpi enables you to use arrays. You can define arrays of numbers or strings as follows:

const MAX_CARDS = 520;

var S1, S2 : array[1..MAX_CARDS] of byte;
Names : array[1..10, 2..50] of string;

In the above code, the variables "S1" and "S2" are both defined as arrays of strings. They both have a single dimension and that dimension ranges from 1 thru 520.

Delphi also enables you to define constants. Constants can be used in the definition of arrays to specify the dimensions of the arrays.

The constant MAX_CARDS is defined as the number 520; It is used in the definition of the array "Names".

The array "Names" has two dimensions. The first dimension ranges from 1 thru 10. The second dimension ranges from 2 thru 50.

You can Google "Delphi programming" if you want more information about how to program in Delphi. But I hope that if I provide you with some of the basics of the language,
it should be sufficient to enable you to understand how my sim works. There is a wealth of info on the web concerning Delphi and how to use it.

[Freightman]

Fortran does have a looping mechanism. The last time I saw it used was 15-20 years ago. I knew a programmer who was active in oil and gas applications, and he was one of the few around who still used it - at that time.

[Frank Galvin]

Skyler,

Is your simulator coded in Delphi? Future revisions and iterations to be issued through Delphi?

I checked out Delphi on Embacadero's website. Unfortunately it appears that you have to run Delphi through RAD with Firemonkey on a MS Windows machine, and an OSX based machine can then be configured by a link to the running windows installation.

I only have apple devices - macbooks, mac minis, ipads and iphones. So it appears at first blush that I will not be able to code, but I can still follow along.

[Skyler62]

Sorry. Duplicate post.

[bigedge]

OP is correct in that a simple HI/Lo +- count will frequently misrepresent precise playing decisions. Sidecounts can mitigate this, but the human mind can only keep track of so much.

A sidecount of 9s makes 13 v. 4 decision much more precise than a general +- count.

9s also make a good sidecount playing 9 v. 7, i.e. double when 9s are rich.

Some systems sidecount 10s simply because they are so important in so many plays.

[Freightman]

OP is correct in that a simple HI/Lo +- count will frequently misrepresent precise playing decisions. Sidecounts can mitigate this, but the human mind can only keep track of so much.

A sidecount of 9s makes 13 v. 4 decision much more precise than a general +- count.

9s also make a good sidecount playing 9 v. 7, i.e. double when 9s are rich.

Some systems sidecount 10s simply because they are so important in so many plays.

Very interesting first post bigedge.
Also 12 v2 in monster counts, adjusting insurance decisions when playing halves, etc.
Look forward to further posts.

[Skyler62]

Frank,

My simulator is coded in Delphi v4. It is an older version of the language but it everything required plus a ton more.

It runs under Windows. I don't know what to tell you if you don't have a Windows machine. I don't know anything about Apple hardware or software.

I've kept the code very simple and so I suppose that if you have access to some Apple programming tools, you could always translate the software from Delphi to whatever Apple applications you may have. But I wouldn't recommend that unless you have a whole lot of time on your hands and a burning desire to do that.

Is there any way I can send you a private message? I can't seem to see any way to send private messages on this site.