Perfect Blackjack Software

Beyond understanding card counting basics, my blackjack advantage play knowledge is minimal. For various reasons I want to create a blackjack program which will tell me the perfect play based on the remaining deck composition, and up cards on the table. I would want the result in approximately 5 seconds. I do not want to hear arguments about how doing this above card counting only provides a minimal advantage.

At first I thought Casino Verite would have a tool to do that but I haven't found out how. If that is the case would someone please walkthrough the steps to configure?

If not, any other available software on the market that does this?

Also, I would be willing to explore creating my own program. Pretend I have infinite computing resources. I would be willing to use hadoop clusters and/or CUDA GPU programming to increase resources to meet the program requirement of perfect play in 5 seconds. For reality, let's assume "perfect" may mean a 5 sigma accuracy (99.99999%)

Are there any examples of algorithms (simulation or combinatorial analysis) online or in books which would put me on on the right track to write my own software?

Thank you!

Way above my head...

What language will you be writing this in? Honestly it shouldn't be that hard as I've written a desktop application that keeps count and suggests moves using BS. You won't need a supercomputer to do it and it might take maybe 60-80 hours to program (without a fancy GUI)

Do you have programming experience? Need some more info to better help you out.

I don't think the five second bit is the tough part. Imagine if you put a BS chart into a 2 dimensional array, the correct play would appear to be found instantly, and even if the chart were an order of magnitude or two larger it would still easily breeze in under 5 seconds.

So, if you could find the info you need* or an algorithm to generate it, you could put it in a lookup table and away you go.

* The problem as I see it is determining what the proper play really is for every possible combination of deck make ups and rule sets. How many trials of each combination will give you the accuracy you require?

You may have a need for those infinite computing resources before you ever get started.

Compared to divining the answer to the real question here writing your program will be trivial.

Somebody on here about a year ago posted about wanting to have Casino Verite use a different counting system. They ended up emailing the developer, who was very helpful. Might be worth a shot.

Here's the thread, which might be useful since it links another piece of modifiable Blackjack software.

You don't need fancy clusters and five sigma accuracy to do this. There is no computational complexity here. A program to calculate what you want could run on a mobile phone. The only problem is it's going to take you way more than five seconds to input the deck composition. No technical complexity either, I can't imagine a first year CS student worth the money he spent on tuition not being able to write it in a few hours.

Quote: weaselman

You don't need fancy clusters and five sigma accuracy to do this. There is no computational complexity here. A program to calculate what you want could run on a mobile phone. The only problem is it's going to take you way more than five seconds to input the deck composition. No technical complexity either, I can't imagine a first year CS student worth the money he spent on tuition not being able to write it in a few hours.

Assuming a large enough screen to comfortable hold the UI, you could have a picture of all 52 cards on the screen (in suited rows or columns) and just touch the card you want to input. Or, for two touches just 2-A and the suits. Then the counting and deck composition could be handled for you.

But I still stand by that it would be trivial to program the app, it's knowing what the correct play is considering number or decks, rule set, and remaining cards.

Here's the problem: suppose you have a 13 and the dealer is showing a 4.
"Perfect play" has to compute the following:
You draw an ace, and then it has to determine the "perfect play" based on you having 14 and the dealer showing 4 (and there is one fewer ace in the deck).
You draw a 2, and then it has to determine the perfect play based on you having 15 and the dealer showing 4 (and there is one fewer 2 in the deck).
And so on, with 3 through 7. (Obviously, with an 8, you stand on 21, and with a 9 or higher, you bust.)
Now, when determining what the perfect play is for 14 with dealer showing a 4, you have to repeat this process - what if your second draw is also an ace, what if it is a 2, and so on.

Assuming you have the computing power to do that in five seconds, it's reasonably simple; you need an array to represent the queue of cards you draw. It appears that the method is similar to the one I for one use to determine what the probabilities are for the house getting 17, 18, 19, 20, 21, or busting from a full deck based on up card, the number of decks, and whether the house hits or stands on a soft 17.

On the other hand, if you want to know what the "perfect strategy" is based solely on what your initial two cards and the dealer's up card are (as well as what cards remain in the deck), the real problem isn't figuring it out, but using the information; you need to know what to do for each possible card drawn, then, for when you hit, each possible card drawn after that, and so on.

Quote: Fiziks

What language will you be writing this in? Honestly it shouldn't be that hard as I've written a desktop application that keeps count and suggests moves using BS. You won't need a supercomputer to do it and it might take maybe 60-80 hours to program (without a fancy GUI)

Do you have programming experience? Need some more info to better help you out.

I'm partial to C++. I have experience - computer engineering major and computer science minor. I'm five years our of school and programming isn't something I do everyday, but I've kept fresh over the years.

Quote: MonkeyMonkey

I don't think the five second bit is the tough part. Imagine if you put a BS chart into a 2 dimensional array, the correct play would appear to be found instantly, and even if the chart were an order of magnitude or two larger it would still easily breeze in under 5 seconds.

So, if you could find the info you need* or an algorithm to generate it, you could put it in a lookup table and away you go.

* The problem as I see it is determining what the proper play really is for every possible combination of deck make ups and rule sets. How many trials of each combination will give you the accuracy you require?

You may have a need for those infinite computing resources before you ever get started.

Compared to divining the answer to the real question here writing your program will be trivial.

Yes the algorithm is the key part I need help with. Combinatorial analysis looks like the right approach. I don't believe I can run a simulation each time new information is received quickly enough. Also a look up table for all rule types would be infeasible.

Quote: heather

Somebody on here about a year ago posted about wanting to have Casino Verite use a different counting system. They ended up emailing the developer, who was very helpful. Might be worth a shot.

Here's the thread, which might be useful since it links another piece of modifiable Blackjack software.

Great idea. I'll e-mail them! Rather not recode the wheel if I don't have to.

Quote: weaselman

You don't need fancy clusters and five sigma accuracy to do this. There is no computational complexity here. A program to calculate what you want could run on a mobile phone. The only problem is it's going to take you way more than five seconds to input the deck composition. No technical complexity either, I can't imagine a first year CS student worth the money he spent on tuition not being able to write it in a few hours.

The combinatorial algorithm is the issue. I can't find a good one to get me going.

For example dealer 9 vs player 9. I can compute dealer probabilities for ending up with 17, 18, 19, 20, 21, BJ, Bust. What do I do from there? How do I determine if I should hit or double?

Quote: scottybweyy

Quote: weaselman

You don't need fancy clusters and five sigma accuracy to do this. There is no computational complexity here. A program to calculate what you want could run on a mobile phone. The only problem is it's going to take you way more than five seconds to input the deck composition. No technical complexity either, I can't imagine a first year CS student worth the money he spent on tuition not being able to write it in a few hours.

The combinatorial algorithm is the issue. I can't find a good one to get me going.

For example dealer 9 vs player 9. I can compute dealer probabilities for ending up with 17, 18, 19, 20, 21, BJ, Bust. What do I do from there? How do I determine if I should hit or double?

You said you had programming experience, haven't you?

Well ... It is not going to be "perfect" if you start with the dealer's probabilities, but, probably, close enough.
So, you know the probability of each total the dealer ends up with, right? Suppose, you are going to double. You can figure out the probability of getting any card. If you get an ace, you will push if the dealer has 20, lose if he gets 21 (there cannot be a BJ), and win otherwise. You know the probability of each individual event, so, you can some them up to get a probability of a win (P), and a probability of a loss (Q). Multiply them by amount you get/lose in each case (2 and -2 respectively), and add them up: 2*(P-Q). This is your conditional expectation given that you receive an ace. Multiply that by the probability of getting an ace, and put aside for now.
Now, consider that your next card is a 2. You win if the dealer busts, and lose otherwise. Do the same calculations as above to get conditional expectation, multiply that by the probability of getting a 2, and put aside. Repeat for all other cards, 3-10.
Now sum up all the values you have calculated. The result is your overall expectation in case you double.

Repeat the same calculations assuming that you hit (except, the amount you win/lose is now 1, instead of 2, and you can get more than one card, so, you'll have to do it in a loop, kinda the same procedure you used to calculate the dealer's probabilities). Don't forget to adjust the probabilities after you draw each card (to be really "perfect", you would also need to recalculate the dealer's probabilities the same way for each you your final hand compositions, not start with the preset numbers as you suggest).

Now, compare the two expectations. If the first one is higher, double, otherwise, hit.

So the simplified algorithm would be something like the below?

1. If dealer has an ace, after step 2, determine if you should take insurance if applicable
2. Determine dealer probabilities of 17, 18, 19, 20, 21, and bust
3. If player total is greater than 11, determine EV of standing
4. Determine EV of hitting
5. If player has a pair, determine EV of splitting
6. IF EV of standing is greater or equal to hitting, determine if you should surrender if applicable
7. If EV of hitting is greater than standing, determine EV of doubling
8. Choose highest EV to make decision
9. If hitting so splitting is best decision goto 2
10. Else end

I doubt it, but is it ever possible to have an EV of hit < stand < double?

Can you elaborate what you meant "It is not going to be "perfect" if you start with the dealer's probabilities, but, probably, close enough."?

Thanks for all the help!

Quote: scottybweyy

I doubt it, but is it ever possible to have an EV of hit < stand < double?

Yes, it is possible. For example, soft 18 vs. dealer's 3-6.
I would recommend to get rid of the conditionals in your algorithm, and just always find out the hit/stand/double/split expectations, and then pick the highest.

Quote:

Can you elaborate what you meant "It is not going to be "perfect" if you start with the dealer's probabilities, but, probably, close enough."?

Well, to be precise, dealer's probabilities will actually be slightly different, depending on your final hand composition, because drawing cards from the deck to complete your hand changes the probabilities of the dealer getting a particular card. So, for complete accuracy, you should be figuring out dealer's probabilities anew every time you evaluate a standing decision, the same way you figure out a hit for a player - recursively draw cards one by one, adjusting probabilities until you reach 17 or more.

The approach has finally clicked for me! Thank you for all the help.

I am still trying to wrap my head around a combinatorial approach to splitting and other minor blackjack rules. Some more questions!

1. I have never been in this situation but it is important to the algorithm. Assume a casino allows splitting to 4 hands and I have 88. Can I re-split the first 8 two times or can each original 8 only be re-split once?

2. How does an unknown burn card alter the approach of the calculations?

3. From what I have seen, most composition dependent combinatorial analysis (CDCA) only approximates pair splitting when re-splits are allowed. The information is a little above my head right now and I plan to keep reading and experimenting more. Splitting only once is the easiest, re-splitting is hard, fixed strategy and optimal strategies are frequently discussed, and the probability of each hand decision is intertwined with the other are my current takeaways from the forum at bjmath and blackjackinfo. For each split, this seems it would double the order of magnitude for an application using a tree structure for each split. Can someone can provide me advice or links that might get me on the right track on the pros and cons of different CDCA splitting approaches?

I think you should start with a simple blackjack program that just follows basic strategy, and then add in new cases to follow that will determine how to adjust play based on count/true count.

If you are trying to calculate your own basic strategy each time the deck changes, that will require running millions of simulations on the current hand that you have and track win/loss/pushs. Then you can calculate what the best move would have been in that situation. You would need a ton of processing power to calculate this in 5 seconds

Quote: javedwahid

If you are trying to calculate your own basic strategy each time the deck changes, that will require running millions of simulations on the current hand that you have and track win/loss/pushs. Then you can calculate what the best move would have been in that situation. You would need a ton of processing power to calculate this in 5 seconds

You don't need simulations, you know exact distribution, and nothing is stopping you from calculating the theoretical expectation. 5 seconds is ample time to compute it without need for supercomputer.

Quote: scottybweyy

1. I have never been in this situation but it is important to the algorithm. Assume a casino allows splitting to 4 hands and I have 88. Can I re-split the first 8 two times or can each original 8 only be re-split once?

You can keep splitting until you have a total of 4 hands. Does not matter which hands exactly are split.
In other words, yes, you can resplit the first eight twice.

Quote:

. How does an unknown burn card alter the approach of the calculations?

It does not. Ignore it, it does not matter.

Quote:

3. From what I have seen, most composition dependent combinatorial analysis (CDCA) only approximates pair splitting when re-splits are allowed. The information is a little above my head right now and I plan to keep reading and experimenting more. Splitting only once is the easiest, re-splitting is hard,

I don't see how the number of hands you are allowed to split to makes any difference. As long as there is a limit, the logic of calculating the EV is exactly the same. If splitting is unlimited, it does change things but not in a very significant way.

Quote:

fixed strategy and optimal strategies are frequently discussed, and the probability of each hand decision is intertwined with the other are my current takeaways from the forum at bjmath and blackjackinfo. For each split, this seems it would double the order of magnitude for an application using a tree structure for each split.

"Double the order of magnitude"? That would be terrible. :)
No, it's linear. If you can split to two hands, you'll need 2x calculations, if the limit is four, then 4x. Nothing exponential.

Quote:

Can someone can provide me advice or links that might get me on the right track on the pros and cons of different CDCA splitting approaches?

There are no pros. I would say it in the beginning, but you mentioned that you did not want to hear it in the first post. Especially in a shoe game, the overall probabilities change so insignificantly with each card drawn, that makes it entirely impractical to perform such exact calculations in the first place. Besides, even if it made any sense, there would be no real use of such a program because you cannot use it in a real casino (except online, but there the shoe is typically reshuffled after every hand, and, if not, the rules are so bad, that you are much better off using basic strategy elsewhere). The term "composition-dependent strategy" you mentioned is usually used to refer to the composition of the hand, not the remaining shoe. There are ways to take the composition of the shoe into account too ("indexes"), but those are based on aggregated information ("true count") about the distribution, not the exact knowledge of every single card.
The program you are talking about may be an interesting theoretical tool (I for one, am curious to see how much of an effect on the house edge such a perfect strategy would have), but does not have any practical applications AFAICS.
If splitting is the only thing left that scares you, I suggest that you start with a calculator for a strategy where splitting is not allowed at all. You can add splitting later, when you get more comfortable with the entire algorithm (and are able to see, that there is not much, if anything, special about calculating split EV compared to all other decisions).