I think I found a serious flaw in most Counting Systems

[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.

[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.

[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.

[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.

[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.

[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]

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.

[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.

[bigedge]

Insurance is another reason to sidecount 10s; it provides a very precise decision to (not) insure.

The most sensitive effect of 10s I can think of is 11 v. A, i.e. hit when 10s are thin. EOR is about 4% in DD.