Blackjack programming forum/resources?

Hello all,

I'm new to this forum and relatively new to blackjack programming. I was wondering if anybody knows of a forum specifically for blackjack programmers, or if people are welcome to ask programming questions here.

I would be interested to know how other developers have attacked certain problems, if they are willing to share. For one, I can't figure out how to calculate exact EVs for splitting so my software has to resort to Monte Carlo simulation. Another problem I ran into is that I couldn't figure out a way to calculate exact EVs when the user specifies a high-low count, so again, I had to resort to simulation.

Thanks in advance for any pointers/insight.

-Tom

Are you familiar with software from qfit.com? Excellent software already exists. I would strongly suggest you check it out at:
http://www.qfit.com/index.htm

You will find simulation software on that site which is superior in many ways. You may be trying to recreate what already exists. And Norm provides outstanding support for his products.

Thank you for the reply. Programming is a hobby of mine and I wanted to make my own software.

I am less interested in using Monte Carlo simulation to calculate EVs and more interested in algorithms that can calculate exact EVs.

I have come up with an algorithm that can calculate exact EVs for standing, hitting, and doubling given any hand, any dealer up-card, any rules, and any particular state of the deck. But my "search tree" explodes when I try to calculate EVs for splitting.

I also have an idea for calculating an *almost* exact value for the house advantage, and calculating the betting advantage given a particular deck, although it would take about 1.5 minutes on my desktop computer.

Tom Kerrigan,

At the link below you'll find the download page for MGP's Blackjack Combinatorial Analysis Software. This free software, among its many other features, allows you to specify the exact composition of the shoe (which it calls a "forced shoe"), from which it calculates the precise EV as well as the correct playing strategy for that forced shoe.

For example, if you specify a 6D, S17, DA2, DAS game, then remove six 3's and six 5's (so the HiLo TC is +2.08), it'll tell you that the player's EV is +0.859374570782053% for a "Total Dependent Strategy", +0.860479320752699% for a "2-Card Dependent Strategy", and +0.860846339786797% for a fully "Composition Dependent" strategy. Furthermore, for this forced shoe you should (among other changes from BS) Stand on 16 vs. 9, since the Stand EV is -0.551... (so -55.1%), while the Hit EV is -0.554... (so -55.4%). It actually shows a lot more decimal places, but I couldn't copy & paste them.

I doubt it'll run on a smartphone, and it isn't terribly fast, requiring 10-15 seconds (on my laptop) to perform all its calculations once you specify the forced shoe. However, it should give you something against which to check your results.

Hope this helps!

Dog Hand

This is great Dog Hand, it does help a lot. I will try the software later this afternoon on a Windows computer.

I am not too worried about the accuracy of my "exact" algorithms since I've tested them extensively vs. Monte Carlo simulations.

But this shows that MGP has found a way to calculate EVs for splitting exactly, which I wasn't sure was possible. I would be very interested to know how he's doing this, if he's willing to share. Unfortunately I tried emailing him at the address supplied with the software but got a message delivery error. Do you guys know if he reads this forum?

His method for calculating the overall EV of a game is a great idea. My idea was to calculate the EV for every cell of the basic strategy table and then do a weighted average of that according to how likely it was to hit each cell. He seems to remove the table altogether and just calculate the EVs for every possible hand which is what you really should do. Unfortunately my code would take about 45 minutes to do what his does in 10-15 seconds, so he's clearly doing something very different than what I'm doing.

One difference is that he seems to assume a particular strategy. My code calculates the optimal action for every possible decision while it's "searching" and thus returns "optimal" EVs but I wonder if that's even useful for blackjack players. I'm not sure it's possible for a human to make the optimal decision in every possible situation. I have not tried calculating split EVs assuming any particular strategy... that might simplify things enough that I could calculate them in a reasonable amount of time.

Thanks again for the information!

Not sure if you're familiar with BJA3 and Cacarulo's work I'm guessing no), but Appendix A also has precise expectations for evryting, with all the methodology explained in the prefatory text.

Don

>>Unfortunately my code would take about 45 minutes to do what his does in 10-15 seconds, so he's clearly doing something very different than what I'm doing.

Darnit, this estimate wasn't very good.

My code can calculate the 300 cells of the basic strategy table in about 50 seconds (using Monte Carlo for splits). So that averages out to 6 scenarios/hands per second, although the split cells take disproportionately longer, but I'll stick with 6 to be conservative.

Every possible hand would be approx. 14^3 = 2744 hands, and divide by two since the order of the player's cards doesn't matter. (I think that's valid?)

So my code could go through every action for every hand in (conservatively) 3.8 minutes. And my code to calculate a single strategy table isn't multithreaded, so I could speed that up roughly the number of cores in a processor. So, for 4 cores, we're looking at a conservative ~1 minute to calculate the same number.

It's not the 10-15 seconds you're seeing on your laptop but it's not as far off as I originally thought!

Thanks Don, I didn't realize that your book also had an explanation of the algorithms used. I do want to buy the book but I would be ordering it online and I'm traveling in a few days and I'm worried that it will be delivered while I'm gone. So that will have to wait for a few weeks.

I was not familiar with Cacarulo's work but you mentioning that name allowed me to find this page via Google:

http://www.blackjackinfo.com/bb/showthread.php?p=216627#post216627

This is exactly the discussion I was hoping to have/find. It looks like people are agreeing that calculating exact split EVs is computationally not feasible (which is the conclusion that I also came to) and are doing approximations by calculating EVs for certain post-split hands independently and combining them. I started going down that route myself a couple months ago but gave up pretty quick when I wasn't sure that such an approximation would be any more accurate than Monte Carlo simulation. I'm sure other people have confirmed that the approximations are as good or better though.

I will consider reading these posts in more detail later and possibly writing my own similar approximation code.

Thank you for the information!

QFIT products and service are unsurpassed. QFIT does not produce a combinatorial analysis blackjack program. MGP's combinatorial analysis blackjack program is free, its license is for non-commercial use and it only calculates basic strategy; it does not calculate indices for card counting systems. Your opening is for a combinatorial analysis blackjack program that calculates indices and expected value for card counting systems, as well as for basic strategy, and whose license is for both personal use and commercial use, i.e. for players and system developers.

QFIT software comes with printed manuals and CDs. Norm is very responsive to questions from customers. QFIT software supports very extensive rules variations and bonuses. QFIT products are not inexpensive, but they are very reasonably priced. Here is your business model.

I look forward to buying your combinatorial analysis blackjack program. I am a low stakes infrequent player, but i am interested in the mathematics of blackjack.

>> Your opening is for a combinatorial analysis blackjack program that calculates indices and expected value for card counting systems,

Thank you for the survey of current software. This is an interesting idea. Unfortunately I don't know how computationally practical it is to use combinatorial analysis to calculate such EVs.

Certainly you can do combinatorial analysis to calculate strategy for a particular deck composition. Another poster indicate that it takes MGP's software 10-15 seconds to do this. But there are many different deck compositions that result in the same count. Maybe thousands or maybe even millions, I'm not sure. I could try to do some investigation to figure out this number if you're interested. (?) But you'd be looking at 15 seconds * thousands, which is a LONG time. :(

>> I look forward to buying your combinatorial analysis blackjack program. I am a low stakes infrequent player, but i am interested in the mathematics of blackjack.

Actually I am currently selling a blackjack game for iOS that contains my algorithms. It's called "Blackjack X." It has a feature that will display EVs in real-time next to the buttons for the different actions as you're playing the game, and it has a feature that I call "Hand analyzer" which allows you to quickly type in a hand and it will quickly calculate EVs for every action for that hand. You can specify different rules and the EVs will be calculated accordingly, and you can also specify a high-low count and see corresponding EVs. (Admittedly only calculated using Monte Carlo simulation but still interesting IMO.)

You will need to buy the $6 upgrade to the "Ultimate version" to use these features but I am happy to give some promotional refunds to people who are blackjack enthusiasts or who are interested in blackjack programming or math. Please send me a private email and we could arrange something.

Here is a screen shot of Blackjack X showing "actual shoe odds":
http://www.roamingtrek.com/blackjackx/realtimeodds2.php

And some screen shots of the Hand Analyzer feature:
http://www.roamingtrek.com/blackjackx/handanalyzer.php

In your game, you have the back of the dealer's downcard fully visible, partially covering the dealer's upcard. That makes no sense. If you don't want the two cards to overlap perfectly, as they do in a real game, then, by all means, have the dealer's upcard completely visible and partially covering his downcard.

Don

Hi Don,

Thanks for the feedback. I'm not entirely sure how my game ended up this way. I used this YouTube dealer training video as a reference for a lot of stuff:

https://www.youtube.com/watch?v=xg_WX6Cj0FA

In the video, Heather clearly deals the first card face down, and the 2nd card face up on top of it, completely obscuring the face-down card, as you describe.

But the Wikipedia article on blackjack (and a few other pages I found) clearly indicates the opposite order. I also just checked 3-4 of the top blackjack apps for iOS and they seem to deal the cards in the same order and display them in the same way as my app.

So I admit confusion -- is it possible that the order is up to the dealer/casino?

I am not opposed to changing my app to correct this if it's wrong but I'd like to make 100% sure first. It would be a fairly straightforward change, but not trivial, since several of my animations would have to be reworked and some of my EV calculating code depends on the 2nd card being the face-down card.

I don't think it makes much difference to gameplay since a lot of the dealer's upcard is still visible... just as much as the player's initial card, which obviously has to be easy to read/recognize too. But of course I would like the app to be realistic and correct.

Thanks,
Tom

Tom, one of the things that got you in trouble over at Norm's site is that you came there as a rank novice in the area but quickly began to take exception to advice that was given to you. My best suggestion to you is: don't do the same thing here!

I'm not going to spend five seconds discussing this. The dealer's DOWN card goes underneath his UP card. Period. How would you want players to clearly see the dealer's upcard if it were obscured by being partially covered by the face-down card? How stupid would that be? THINK!

Don

>>Tom, one of the things that got you in trouble over at Norm's site is that you came there as a rank novice in the area but quickly began to take exception to advice that was given to you.

Sorry Don, I tried my hardest to make it clear that I was willing to change my app, and not taking exception to your feedback; I just wanted to confirm. No offense or frustration intended. I think it's not unreasonable to want to confirm since the top iOS apps work the same way mine does.

>>How would you want players to clearly see the dealer's upcard if it were obscured by being partially covered by the face-down card? How stupid would that be? THINK!

My understanding is that dealer cards are never placed such that they are partially overlapping, so in a real game of blackjack, none of the cards would be obscured.

This is how my app worked for a couple weeks, but this is impractical on a small cell phone screen because if the dealer hits to 4-5+ cards, the cards must be drawn so small that they quickly become illegible.

So I made the decision to draw the dealer cards such that they're partially overlapping, the same as the player's cards.

Once I made them overlap, I could no longer draw them being dealt to the player's left, because then the player would only be able to see the right edge of the cards and thus have to read the dealer's cards upside down.

So in case anybody is wondering why my app draws overlapping dealer cards and doesn't show dealer cards being dealt to the player's left, that's the rationale.

"Sorry Don, I tried my hardest to make it clear that I was willing to change my app, and not taking exception to your feedback; I just wanted to confirm. No offense or frustration intended. I think it's not unreasonable to want to confirm since the top iOS apps work the same way mine does."

Tom, how many hands of blackjack would you guess I've played in the past 40 years? Do you think I might have noticed how the dealer's cards are arranged by now?

"My understanding is that dealer cards are never placed such that they are partially overlapping, so in a real game of blackjack, none of the cards would be obscured."

That's totally incorrect. The bottom card is COMPLETELY obscured. It is flush underneath the upcard so that, if the dealer isn't sloppy, you can't see that it's there at all.

"This is how my app worked for a couple weeks, but this is impractical on a small cell phone screen because if the dealer hits to 4-5+ cards, the cards must be drawn so small that they quickly become illegible.:

Make the downcard protrude ever so slightly, just enough so that one can see that it exists. It's the upcard that needs to be clear. Go here, for example, and have a look at how it should be done:
http://www.blackjackinfo.com/aftergame.php

"So I made the decision to draw the dealer cards such that they're partially overlapping, the same as the player's cards."

Fine. Put the downcard UNDER the upcard. LAST discussion of this for me.

"Once I made them overlap, I could no longer draw them being dealt to the player's left, because then the player would only be able to see the right edge of the cards and thus have to read the dealer's cards upside down."

Can be avoided. Think about it.

"So in case anybody is wondering why my app draws overlapping dealer cards and doesn't show dealer cards being dealt to the player's left, that's the rationale."

The hole card needs to be "flipped" to the dealer's left and player's right, as it is done in the real world. Counters need to see the cards as they are accustomed to seeing them dealt. then, the hit cards need to be done in reverse: dealer's right, player's left.

Don

Just so you know, BJ Trainer shows the hole card properly obscured, but deals backwards; i.e., they flip the hole card to the player's left and put hits to the right, which is reverse of what is correct procedure.

Don

>>That's totally incorrect. The bottom card is COMPLETELY obscured. It is flush underneath the upcard so that, if the dealer isn't sloppy, you can't see that it's there at all.

Sorry, I was trying to make a distinction between partially overlapping cards and completely overlapping cards, to answer your question about why a dealer would partially obscure his upcard (i.e., he wouldn't).

I do appreciate the feedback and I'm changing my app as we speak to reflect this change. I'm sorry if I caused any frustration.

>>Just so you know, BJ Trainer shows the hole card properly obscured, but deals backwards; i.e., they flip the hole card to the player's left and put hits to the right, which is reverse of what is correct procedure.

Since I'm changing this, could I run my intended changes by you so I can make sure I'm doing the right thing?

My intention was to
1) Change my app so the dealer's hole card is dealt first
2) Deal the upcard exactly on top of the hole card (unless you think it's useful to show them slightly overlapping as they do at the BJ Trainer link you posted? I don't understand why this would be useful on a computer but not in real life...)
3) Change the dealer's hit cards so they are dealt to the player's left ... I think this means that I will have to draw all of the dealer's hit cards upside down, so the overlapping ones don't have to be read upside down. I can't think of any way around this. Do you have a suggestion?

Really appreciate your time.

"Since I'm changing this, could I run my intended changes by you so I can make sure I'm doing the right thing?

"My intention was to
"1) Change my app so the dealer's hole card is dealt first>

That doesn't much matter, so long as it winds up UNDERNEATH the upcard. Some casinos deal the hole card first; others the upcard and then the hole card is slid underneath. Doesn't matter for the app.

"2) Deal the upcard exactly on top of the hole card (unless you think it's useful to show them slightly overlapping as they do at the BJ Trainer link you posted? I don't understand why this would be useful on a computer but not in real life...)"

Agree. In real life they are always squared up. On the app, maybe, for novices, they just want to show that a hole card is actually there. A slight overlap won't hurt.

"3) Change the dealer's hit cards so they are dealt to the player's left ... I think this means that I will have to draw all of the dealer's hit cards upside down, so the overlapping ones don't have to be read upside down. I can't think of any way around this. Do you have a suggestion?"

Yes, don't make them overlap. The vast majority of hands comprise only three or four cards. You can fit that with no overlapping, no? If you need more room, move the cards over, or overlap them only at that point.

Don't forget to flip the hole card to the dealer's LEFT.

"Really appreciate your time."

Trying.

Don

>>That doesn't much matter, so long as it winds up UNDERNEATH the upcard. Some casinos deal the hole card first; others the upcard and then the hole card is slid underneath. Doesn't matter for the app.

I see, I realize now after watching Heather's video again that I misunderstood what was going on. She deals the first card face-down but it's actually the up card. Then she deals the hole card face down and the last step of the deal is to flip the up card up on top of the hole card.

So it seems like there's general agreement that the up card is usually dealt first. I didn't know this last night--I assumed the up card would be dealt face up, and I couldn't figure out how the up card would get on top of the hole card if it was being dealt first. Good to know that I won't have to change this in my app... not that it would have been too hard but it would have been annoying to test everything again to make sure I didn't mess up any of the changes to the EV calculating algorithms.

>>Yes, don't make them overlap. The vast majority of hands comprise only three or four cards. You can fit that with no overlapping, no? If you need more room, move the cards over, or overlap them only at that point.

On the iPhone screen I can fit two cards at the "default" size (the size you see in all of the screen shots) but not three. At that point the cards have to start shrinking, which looks kind of cool but is also pretty distracting--imagine all the cards of a hand shrinking and changing position as each new card is dealt. Once you get to four cards, being able to see them becomes kind of an issue. Remember that a cell phone screen is around 2 to 2.5 inches wide so you're talking about cards taking up half an inch or less at that point. Certainly 5 cards is extremely difficult to see, and if I start overlapping them, then it's back to the problem of having to read their right-hand edges, which are upside-down.

Considering all this, I might resign myself to the idea that my app, when running on an iPhone, is probably not a good tool to train people to count cards.

I will put an item on my to-do list to give the user the choice of a more realistic layout for the dealer's cards. I imagine this would look fine on an iPad, especially if it's in landscape mode.