# Algorithms: Find the best table to play (standing gambler problem)

Preface

This is not code golf. I'm looking at an interesting problem and hoping to solicit comments and suggestions from my peers. This question is not about card counting (exclusively), rather, it is about determining the best table to engage based on observation. Assume if you will some kind of brain implant that makes worst case time / space complexity (on any given architecture) portable to the human mind. Yes, this is quite subjective. Assume a French deck without the use of wild cards.

Background

I recently visited a casino and saw more bystanders than players per table, and wondered what selection process turned bystanders into betting players, given that most bystanders had funds to play (chips in hand).

Scenario

You enter a casino. You see n tables playing a variant of Blackjack, with y of them playing Pontoon. Each table plays with an indeterminate amount of card decks, in an effort to obfuscate the house advantage.

Each table has a varying minimum bet. You have Z currency on your person. You want to find the table where:

• The least amount of card decks are in use
• The minimum bet is higher than a table using more decks, but you want to maximize the amount of games you can play with Z.
• Net losses, per player are lowest (I realize that this is, in most answers, considered to be incidental noise, but it could illustrate a broken shuffler)

Problem

You can magically observe every table. You have X rounds to sample, in order to base your decision. For this purpose, every player takes no more than 30 seconds to play.

What algorithm(s) would you use to solve this problem, and what is their worst case complexity? Do you:

• Play Pontoon or Blackjack ?
• What table do you select ?
• How many rounds do you need to observe (what is the value of X), given that the casino can use no more than 8 decks of cards for either game? Each table has between 2 and 6 players.
• How long did you stand around while finding a table?

I'm calling this the "standing gambler problem" for lack of a better term. Please feel free to refine it.

Where would this be useful if not in a casino?

Final

I'm not looking for a magic gambling bullet. I just noticed a problem which became a bone that my brain simply won't stop chewing. I'm especially interested in applications way beyond visiting a casino.

• Interesting quesiton. I'm not sure this is the right site for this. I don't know why or where it would fit better, it just doesn't feel right here. Perhaps I'm wrong... Commented Nov 30, 2010 at 17:55
• @Walter - I wasn't sure either. There are sites dedicated to various games, but it isn't likely that the users of those sites understand complexity, or even what an algorithm is. It's too 'meta' for SO, I'm wondering if it can find a home here.
– user131
Commented Nov 30, 2010 at 17:57
• I don't know it kinda sounds like a Poisson process. Maybe the people at math.stackexchange.com might know. Commented Nov 30, 2010 at 18:37
• @Conrad, perhaps. However, I suspect someone here might have some ideas, which ended my debate on asking the question in the first place :)
– user131
Commented Nov 30, 2010 at 18:44
• Sorry, but I do not even see a problem statement. I can only assume that the problem is to maximize winnings, then the questions you ask are not important to the algorithm. I don't care how many rounds I observe, I just observe until I have an edge against the house and then I push that edge. If I can always wait until I have an edge and always switch tables to the table with the best edge then the algorithm is very simple. Commented Nov 30, 2010 at 19:34

If I can concurrently examine all tables even while playing then:
Given that all games progress at the same speed for simplicity...(i could adjust for this)

``````
while(not satisfied with winnings)
keepcurrenttable == 1 || Wait for positive count threshold on any one table
if Z/(min bet)>%chance of win*payout
next
else
Play hand according to standard counting rules.
endif
if (%chance of win on another table*payout on another table > same for current) && Z/(min bet)>%chance of win*payout
change tables
elseif currenttable %chance of win*payout >
keepcurrenttable=1
else
keepcurrenttable=0
endif
next

``````

still some bugs in there and doesn't account for EVERYTHING, but you get where I'm going

there's a lot more to %chance of win

number of players should be minimally pertinent(more players == faster burning through decks)

does less players mean I can play more hands concurrently?(that would require heavier weight on player count)

additionally, count threshold could be defined with a risk appetite meter.