Combinatorial Analysis Programming

#21
iCountNTrack said:
I am sorry but I am afraid this is not true, when you do a combinatorial analysis you will have to enlist ALL the possible hands including the ones that a that might appear absurd, like hitting a hard 20. The properly weighing the EV for each decision with its respective frequency, will take care of everything.
But not when you are designing a system to provide a useful decision. You have to use all possible combinations when you are calculating the probability of each hand being dealt in a strictly random environment, but there is no reason to include the likelihood of a player having the hand A,9,6 (in that order) vs. 10 when generating an index for hitting a 3-card 16 vs. 10. How you get your third card is not random, it depends on the input of an intelligent player. That's why it's tricky.
 

k_c

Well-Known Member
#22
assume_R said:
Thanks, k_c, I was hoping you'd chime in on this thread. Thus far, for hitting and standing my results exactly agree with your website's results, except for the Player EV for cards vs. an A, which disagree by only a few percentage points (possibly implementation differences?).

Now I will be implementing splitting, which I am a bit unsure of. So let's say it's 7,7 vs. 2. I then basically just up the EV's of a 1-card 7 vs. 2 and another 1-card 7 vs. 2 assuming both 1-card 7's have to hit?
I suspect the difference for up card of ace might relate to whether it is assumed dealer has first checked for blackjack. There is a checkbox in the 'General' section of program options, 'Display expected values conditioned on no dealer blackjack where applicable'. If this is checked program computes assuming dealer has checked for blackjack and doesn't have it. If unchecked program computes EV for player non-blackjack loses to dealer blackjack. If ENHC or early surrender versus ace is selected as a rule option then the unconditional EV (in ace up card column) is displayed whether or not the box is checked because it makes no sense to say dealer has first checked for blackjack in these cases. In the online version you need to click 'Compute' again after unchecking/checking the checkbox to display the unconditional/condtional values. (In the GUI .exe version EV is automatically changed.)

Splitting is complicated. The online program computes optimal comp dependent EVs for all non-splits as long as the 'Best strategy' option is selected. Splits, however, are not necessarily optimal in my program. The reason is that I could see no way to compute splits optimally in a reasonable amount of computer time. Instead splits are computed predicated upon a fixed strategy. It turns out that in the case of 1 split, if split hand 2 is played using the identical strategy of split hand 1 then hand 2 EV = hand 1 EV. Strategy can be optimal or sub-optimal as long as it's fixed. Eric Farmer's program fixes split hand strategy by using the optimal strategy from all hands that are not splits. In my program you can get these EVs by selecting the 'Basic full shoe CD strategy' along with the 'Full shoe pre-split strat' options. For a full shoe my split EVs for 1 split allowed should agree with Eric's if these options are chosen. For less than full shoe my program still uses full shoe strategy if these options are chosen. I'm not sure what Eric's program would compute for less than full shoe. The other option I have for basic strategy in my program is to fix the split strategy as the optimal strategy of the first hand of a full shoe split. If 'Best strategy' is selected rather than 'Basic full shoe CD strategy' then split strategy is fixed as the optimal strategy of the first hand of a split regardless of shoe composition. Multiple splits are more complicated but still rely upon using a fixed strategy. Basically the procedure my program follows to compute the most optimal split EVs is 1) compute optimal EV of first split hand regardless of shoe composition and 2) apply strategy of first split hand to all subsequent split hands. If it turns out that the optimal strategy of all subsequent hands is also the strategy of the first split hand then computed split EV will be optimal and otherwise a bit sub-optimal.
 

MangoJ

Well-Known Member
#23
Automatic Monkey said:
But not when you are designing a system to provide a useful decision. You have to use all possible combinations when you are calculating the probability of each hand being dealt in a strictly random environment, but there is no reason to include the likelihood of a player having the hand A,9,6 (in that order) vs. 10 when generating an index for hitting a 3-card 16 vs. 10. How you get your third card is not random, it depends on the input of an intelligent player. That's why it's tricky.
Unless you intend to hit a A9 vs 1, right. But there might be an obscure situation where you want to hit a A9 vs 10 - and you might also argue that will never happen in your lifetime. However this will only save you from computing A9X vs. 10. What about other similar hands ? Do you really want to formulate a rule as to "never hit a hard/soft 20" ? Why not drawing the line on 19 or 21. For a program that doesn't mean any real difference to run through a few more hands, and it is more work in implementation (with possibility of introducing new errors).

Also, you might want to know the EV for a hit for other things than purely strategy decisions. You might want to produce an index table, or check a theorem which includes exotic EVs. Then you need that info anyway.
 

London Colin

Well-Known Member
#24
MangoJ said:
Ok, here is a better approach for total-dependent strategy.

Eric Farmers code allows to measure the EV of any kind of strategy.

a) I would start with a total-dependent strategy with most obvious decisions already "guessed". Leaving the marginal decisions open. Should be only a few.
(say 20)
It would actually be quite easy to automate that step. The algorithm I described for extracting total-dependent EVs from the perfect-play results could also generate a list of those decisions which are deemed to be mariginal, based on a user-defined threshold for the difference in EV.

MangoJ said:
b) Iterate through all those open 20 decision configurations (typically 2^20), evaluate EV each, and pick the marginal decision set with maximal EV.

c) Iterate through all decisions, alter them one-by-one (so only ~200 evaluations). If on any those modifications a EV can get better, take this decision, and start back at (b).

When it converges, this is proved to be the best total-dependent strategy.
Sounds like you are thinking along similar lines to those that occurred to me when I looked at this topic a while ago. (Inevitably it became just another of my abandoned projects:)).

The problem is to arrive at a method that is guaranteed to converge on the best solution, but does not take an unfeasibly long time to run.

I'm not sure I totally understand the logic of your method. In step b, is the idea to re-evaluate the overall EV for the game, with each of the 2^20 variations tried out? (If it takes 2s to calculate each one, that would be around 24 days for the full set!)

But if that were done, I'm not sure step c would be necessary, so maybe that's not what you mean?


[An alternative approach might be to seek a proof that none of this is necessary, and that it is enough to merely sum the weighted, perfect-play EVs. It may be that someone has in fact proved this; I don't know.

But even then, it strikes me that it would be nice to have an alogorithm that must necessarily always give the right answer, even if we feed it strange scenarios, like specific deck compositions or unusual rule sets.]
 

MangoJ

Well-Known Member
#25
London Colin said:
I'm not sure I totally understand the logic of your method. In step b, is the idea to re-evaluate the overall EV for the game, with each of the 2^20 variations tried out? (If it takes 2s to calculate each one, that would be around 24 days for the full set!)

But if that were done, I'm not sure step c would be necessary, so maybe that's not what you mean?
24 days are on the edge of being reasonable. However if there are 23 open decisions that is a whole year. Actually those 2^20 open decisions can be split by dealers upcard (as the upcard will not change during a hand), and one ends with 10 x 2^2...3 decision sets, which are dramatically faster to optimize.

Step c is not necessary by itself, but it will verify the result, that all decisions found are indeed the best total-dependent strategy.
 

London Colin

Well-Known Member
#26
MangoJ said:
Step c is not necessary by itself, but it will verify the result, that all decisions found are indeed the best total-dependent strategy.
I'm not sure that's true. It seems to me that this approach is still a heuristic one, in which we cannot be entirely sure that what we have found is not just a 'local maximum'.
 

iCountNTrack

Well-Known Member
#27
As LC had mentioned before, I think the best way to generate total dependent strategy (which is a sub-optimal strategy) would be to work backwards from perfect play composition dependent. So basically you generate all the possible hands(with all the possible permutations) find the best playing decision for each hand , so let's say for instance for a given deck composition there are 20 card sequences with a total of 16, 12 sequences are stand and 8 are a hit. For this deck composition the total dependent strategy for a total of 16 would be to hit.

CA is indeed very cool and what would make it more interesting is when we are able to do it for any deck composition as implemented by k_c. Where you can find very "weird" playing decisions especially in the case of a very depleted single deck and calculate overall pre-deal ev. That is why in a proper CA all possibilties must be included.
 

k_c

Well-Known Member
#28
Total Dependent

An approach I've used to get a player's total dependent hit/stand strategy is to define a specific player strategy with a pair of numbers: minimum soft hand standing number and minimum hard hand standing number. Player hits if his hard/soft total is below the hard/soft standing number, otherwise stands. Splits are played using the same hard/soft standing strategy. If a hand should be doubled, then it is but this means double strategy remains as composition dependent. To get player's best total dependent hit/stand strategy, iterate through all of the possible strategies and choose the one with the best EV.

This method yields a full shoe basic strategy that is a little more optimal than a completely total dependent strategy because doubles and surrenders remain composition dependent. Since doubles and surrenders are the same for each possible player strategy they have no influence on which hit/stand strategy is best but doubles and surrenders would not be total dependent.

Also the resultant strategy would relate to pre-deal, which is what full shoe total dependent strategy does. Using the method on less than a full shoe would yield a new basic strategy specific to that particular shoe comp but would not incorporate knowledge of cards dealt during a round like a counter does. Another thing is with less than full shoe there exists the possibility of exceptions to a computed strategy depending upon actual composition. For example if all 6,7,8,9 are removed from a full shoe this method computes to stand on hard 12 and above versus a dealer up card of 10. In actuality player should stand on 12,13,14,15, and hit 16.

Another method would be to try and filter out all hands that have no bearing on strategy. For example all 2 card hands of hard 11 v T and their children shouldn't be considered because they would be doubled. 8-8 v T wouldn't be considered with other hard 16s because it would be split. However to be correct the post-split hands of 8-8 v T should be considered. Total dependent strategy is a tough nut to crack.
 

assume_R

Well-Known Member
#29
Okay, so since I will be using my program to calculate things such as indices and total-dependent BS, I've essentially not computed a true "CD" program. Firstly, k_c, my "Assume dealer already checked" works exactly the same as yours, and I have been able to duplicate your results, so I know that's not why the EV w/ dealer upcards of A's don't agree. But it's only a few hundredths of a percent that we disagree with, so it's not a big deal. The way I compute it, is I always calculate the dealer's probabilities. If the "already checked for BJ" is selected, then I make the probably of dealer BJ 0, and normalize the remaining probabilities, which is mathematically correct.

Now regarding splits:
I have been able to exactly duplicate your splitting results, for some conditions. I have not been considering the case of how the resulting splitting will change the H/S decisions, because I simply won't ever use that information in real play. What I am doing right now is manually setting the BS for all the other decisions. Then, I will compute the EV of the 2-2 vs. 6, for example, assuming that the player is going to play his resulting hands according to a predefined strategy. I am well aware this is not optimal, but for generating a split decision, or a split index, I don't believe that any player will change his strategy when he considers whether or not he has split 2's already. So I won't be considering that. I plan on going from hard 20 to 4, for all H/S decisions, then soft 20 to 12 for H/S, then hard 20 to 4 doubling, then soft 20 to 4 for doubling, and then lastly I will go through each split, assuming the existing strategy is constant.
 

k_c

Well-Known Member
#30
assume_R said:
Okay, so since I will be using my program to calculate things such as indices and total-dependent BS, I've essentially not computed a true "CD" program. Firstly, k_c, my "Assume dealer already checked" works exactly the same as yours, and I have been able to duplicate your results, so I know that's not why the EV w/ dealer upcards of A's don't agree. But it's only a few hundredths of a percent that we disagree with, so it's not a big deal. The way I compute it, is I always calculate the dealer's probabilities. If the "already checked for BJ" is selected, then I make the probably of dealer BJ 0, and normalize the remaining probabilities, which is mathematically correct.

Now regarding splits:
I have been able to exactly duplicate your splitting results, for some conditions. I have not been considering the case of how the resulting splitting will change the H/S decisions, because I simply won't ever use that information in real play. What I am doing right now is manually setting the BS for all the other decisions. Then, I will compute the EV of the 2-2 vs. 6, for example, assuming that the player is going to play his resulting hands according to a predefined strategy. I am well aware this is not optimal, but for generating a split decision, or a split index, I don't believe that any player will change his strategy when he considers whether or not he has split 2's already. So I won't be considering that. I plan on going from hard 20 to 4, for all H/S decisions, then soft 20 to 12 for H/S, then hard 20 to 4 doubling, then soft 20 to 4 for doubling, and then lastly I will go through each split, assuming the existing strategy is constant.
OK if you're talking about player hand EVs and your EVs are total dependent, then some differences are expected. Total dependent EVs in some cases can equal comp dependent EVs but can be no greater.

The idea I had for my tdca program was to record all pertinent data (rules, composition, player hand, basic strategy hand EVs, best TD strategy EVs if different from basic strategy, # decks, etc.) in a data base each time the program's practice program is used. What you'd have is a never ending sim that could be queried for desired parameters. The problem with simming while recording computed values is that relatively speaking it's not very fast. However, since data is computed it is guaranteed to be accurate so a really huge amount of data wouldn't be needed before results would converge on a value. Just another idea that I never implemented.
 

assume_R

Well-Known Member
#31
I saw some others posting in another thread about count compositions, and I figure I'd discuss it here, as that's the next step once all my EV's agree with k_c's (I haven't found one that doesn't yet, except for some splits).

Here's what I'm going to do:

Generate random amounts of remaining cards. For example in an 8-deck shoe
A-K: [round(32 * rand), round(32 * rand), ..., ]

Then, discard any random shoes where the sum is > than the desired penetration. Then I can simply matrix-multiply by the tags, and get the RC (and then TC) of each "random shoe". This will give me a random distribution of what each TC represents at random different points throughout the shoe. That's what I'm going to be using to generate indices.

Still, with all this data, though, I need to figure out the best way to get total-dependent hands. Will look through this thread later to see what others suggested.
 

assume_R

Well-Known Member
#32
Question: given a set of probabilities, and their EV's
(i.e. 20% chance of getting a 100% return, 50% chance of getting a -100% return, 30% chance of getting a 0% return), is there some mathematical way to get the variance? How exactly did others compute the variance of blackjacks? Just simulations???

Or, once I know that the EV is .2 * 1 + .5 * -1 = -30% for a given hand, can I go back over all my results and get the variance that way?
 

MangoJ

Well-Known Member
#33
assume_R said:
Generate random amounts of remaining cards. For example in an 8-deck shoe
A-K: [round(32 * rand), round(32 * rand), ..., ]

Then, discard any random shoes where the sum is > than the desired penetration. Then I can simply matrix-multiply by the tags, and get the RC (and then TC) of each "random shoe". This will give me a random distribution of what each TC represents at random different points throughout the shoe. That's what I'm going to be using to generate indices.
Be careful with this. If you just sum up your A-K (i.e. 13) random card numbers (0-32) and cut at a threshold, you get an almost gaussian penetration distribution peaked at 50% penetration (i.e. not uniform).
If you want to evaluate the play of a shoe, during play the penetration raises almost linear with number of hands, and hence the real distribution of penetration during play is uniform.

This will bias your results!
 

assume_R

Well-Known Member
#34
MangoJ said:
Be careful with this. If you just sum up your A-K (i.e. 13) random card numbers (0-32) and cut at a threshold, you get an almost gaussian penetration distribution peaked at 50% penetration (i.e. not uniform).
If you want to evaluate the play of a shoe, during play the penetration raises almost linear with number of hands, and hence the real distribution of penetration during play is uniform.

This will bias your results!
You're saying I'll oversample towards the middle of the shoe? That let's say a TC of +2, I will be mostly measuring what a TC of +2 means at the middle of the shoe? That makes sense... How to overcome this then?
 

MangoJ

Well-Known Member
#35
assume_R said:
You're saying I'll oversample towards the middle of the shoe? That let's say a TC of +2, I will be mostly measuring what a TC of +2 means at the middle of the shoe? That makes sense... How to overcome this then?
Yeah. I'm not an expert on this (or any) kind of approach, but I guess if you base your indices on your training data (your random shoes) and the 50% penetration depth (or any other part) is overrepresentated, you optimize your indices mainly on that part. So you underperform during play where all penetrations are reached.

Why not start with a full shoe, and remove a random number of random cards from it ? (with "random" I mean a uniform random number). If you need a shuffled shoe for your program, you can shuffle the full shoe, and discard the last cards.

A standard card shuffle looks like this (pseudo code from Wikipedia):
for i from 8*52 − 1 downto 1 do
j ← random integer with 0 ≤ j ≤ i
exchange shoe[j] and shoe

simply modify it for a certain penetration p:
for i from 8*52 − 1 downto p*(8*52) do

and discard the remaining shoe[i > p*(8*52)]


Personally I would first try to answer the question, whether - given a certain RC - the penetration depth has an effect at all. My guess would be, since the RC is already measuring the compositional distribution of cards, it doesn't matter much, if you have 100 or 1000 cards remaining. But that thinking can easily be flawed, such topics are highly unintuitive.
 

MGP

Well-Known Member
#36
Hi,

A CA should be able to calculate exact values for TD, 2-card and CD strategies for all hands and all splits (SPL1-3) in less than a minute for any number of decks. That should be less than 30s if you're in a second run with a hash table. There is no reason nor any logic to ignoring any hands given the speed of calculations. There is also no reason to make any assumptions or guess anything. That is contrary to the idea of CA.

The numbers you want to match exactly are the ones Cacarulo put in Schlesinger's BJ Attack 3. He and I worked on splits together and verified the exact TD values for the splits and they were verified by brute-force. k_c's values should match with a fixed strategy but I haven't checked out his site. I know he can get exact TD split values though.

It is impossible and a waste of time to calculate exact CD split plays that take into account every card played without brute-force. You can get estimates very quickly though by using the CD playused for full deck but during a split (and even finer tune those with some probability tricks) but it's a ridiculous way to actually play.

The way to determine the best strategy for TD play generically is iterative but really only requires 2 iterations:

1) Keep track of which cards are used during CD hitting and ignore any cards which are not reached during CD play.

2) The first pass first compares TD doubles, splits and surrenders against the CD values for the same and hitting and ignore those hads which are doubled/split or surrendered.

3) Now go backwards and for each total compare the weighted averages of hitting with the actualy hands that are reached vs standing for multi-card plays and determine the strategy. As you go backwards, keep track of the strategy and use it. When you get back to the 2 card hands, recompare the values of standing vs hitting. (This is when you'll see that 16 vs 10 is R, S and not R, H.

4) Do a second iteration but use the new TD hit and split values for any comparisons and before you start play through with the new strategy and again figure out which hands will be reached and ignore any that aren't.

Even with this there is a tiny possibility you could end up with a back and forth between splitting and not splitting since changing the TD strategy changes the split ev (makes it lower compared to CD) but it won't happen with any standard decks and the difference would have to be tiny.

The slight changes you make to the above to figure out N-Card dependent strategies as are needed for Spanish 21 and 2-Card strategies should be obvious.

The ideal way to increase speed, unless you want to hard code hands the way T Hopper does to get all the calcs done in <1s, is to iteratively figure out all hands and then store the dealer probs for each shoe state (in addition to stand, cd hit and double/surrender values (and later TD / 2C hit values) when relevant). See Eric Farmer's program as a good example on how to do this - it's very elegant.

For future calculations, you can create a shoe state hash table that stores the dealer probs for any given shoe state and saves them. I would not do this for multiple numbers of starting decks in one table but keep each number of starting decks as a separate hash table. I.e. the 6D library should be different than the 2D table. Otherwise the library becomes big enough that it actually slows things down and it can take longer to load the table than to do the actual calculations.

If you want exact values for various counts, you need to use burn card probabilities (something I came up with) to calculate exact CD/TC/TD strategies for any given count in less than an hour (a few secs for extreme counts). You have to take a weighted average of all possible depths for each probability calculation/shoe composition (storing them in another hash table saves time). The main problem with this though is that you can't take into account changing strategies as the count changes so it won't actually match how a counter will play so it's not a very useful excersize. The programming is also very confusing and complex. Norm Wattenberg's sim is a better option for more realistic game play calculations since the cut depth also effects the calculations.

It's very fast for insurance calculations which can be done exactly very very quickly. Cacarulo put a bunch of the calcs (he used the hypergeometric distribution) on advantageplayer.com I believe and probably put them in BJA3 (I'm too lazy to go find it and check).

Variances are easily calculated exactly for hitting, standing and doubling. They cannot be easily estimated for splits with any consistency that sim won't beat hands down if you look at all hands (for some the estimates are really close). The can only be calculated with brute force and that is a very difficult calculation that is not worth the time programming or waiting for the calculations. Norm's program is better for these.

Sincerely,
MGP
 

k_c

Well-Known Member
#37
MGP said:
Hi,

A CA should be able to calculate exact values for TD, 2-card and CD strategies for all hands and all splits (SPL1-3) in less than a minute for any number of decks. That should be less than 30s if you're in a second run with a hash table. There is no reason nor any logic to ignoring any hands given the speed of calculations. There is also no reason to make any assumptions or guess anything. That is contrary to the idea of CA.

The numbers you want to match exactly are the ones Cacarulo put in Schlesinger's BJ Attack 3. He and I worked on splits together and verified the exact TD values for the splits and they were verified by brute-force. k_c's values should match with a fixed strategy but I haven't checked out his site. I know he can get exact TD split values though.

It is impossible and a waste of time to calculate exact CD split plays that take into account every card played without brute-force. You can get estimates very quickly though by using the CD playused for full deck but during a split (and even finer tune those with some probability tricks) but it's a ridiculous way to actually play.

The way to determine the best strategy for TD play generically is iterative but really only requires 2 iterations:

1) Keep track of which cards are used during CD hitting and ignore any cards which are not reached during CD play.

2) The first pass first compares TD doubles, splits and surrenders against the CD values for the same and hitting and ignore those hads which are doubled/split or surrendered.

3) Now go backwards and for each total compare the weighted averages of hitting with the actualy hands that are reached vs standing for multi-card plays and determine the strategy. As you go backwards, keep track of the strategy and use it. When you get back to the 2 card hands, recompare the values of standing vs hitting. (This is when you'll see that 16 vs 10 is R, S and not R, H.

4) Do a second iteration but use the new TD hit and split values for any comparisons and before you start play through with the new strategy and again figure out which hands will be reached and ignore any that aren't.

Even with this there is a tiny possibility you could end up with a back and forth between splitting and not splitting since changing the TD strategy changes the split ev (makes it lower compared to CD) but it won't happen with any standard decks and the difference would have to be tiny.

The slight changes you make to the above to figure out N-Card dependent strategies as are needed for Spanish 21 and 2-Card strategies should be obvious.

The ideal way to increase speed, unless you want to hard code hands the way T Hopper does to get all the calcs done in <1s, is to iteratively figure out all hands and then store the dealer probs for each shoe state (in addition to stand, cd hit and double/surrender values (and later TD / 2C hit values) when relevant). See Eric Farmer's program as a good example on how to do this - it's very elegant.

For future calculations, you can create a shoe state hash table that stores the dealer probs for any given shoe state and saves them. I would not do this for multiple numbers of starting decks in one table but keep each number of starting decks as a separate hash table. I.e. the 6D library should be different than the 2D table. Otherwise the library becomes big enough that it actually slows things down and it can take longer to load the table than to do the actual calculations.

If you want exact values for various counts, you need to use burn card probabilities (something I came up with) to calculate exact CD/TC/TD strategies for any given count in less than an hour (a few secs for extreme counts). You have to take a weighted average of all possible depths for each probability calculation/shoe composition (storing them in another hash table saves time). The main problem with this though is that you can't take into account changing strategies as the count changes so it won't actually match how a counter will play so it's not a very useful excersize. The programming is also very confusing and complex. Norm Wattenberg's sim is a better option for more realistic game play calculations since the cut depth also effects the calculations.

It's very fast for insurance calculations which can be done exactly very very quickly. Cacarulo put a bunch of the calcs (he used the hypergeometric distribution) on advantageplayer.com I believe and probably put them in BJA3 (I'm too lazy to go find it and check).

Variances are easily calculated exactly for hitting, standing and doubling. They cannot be easily estimated for splits with any consistency that sim won't beat hands down if you look at all hands (for some the estimates are really close). The can only be calculated with brute force and that is a very difficult calculation that is not worth the time programming or waiting for the calculations. Norm's program is better for these.

Sincerely,
MGP
Hi, MGP. Good to hear from you. :)
 

assume_R

Well-Known Member
#38
Hi, MGP.

So I've already implemented the hash tables for different states as you suggested, for both dealer probability calculations (the number of cards from 0 to 10 with all faces lumped together is the key for this hash table) and EV calculations (the hand state and the deck state, with full suits and ranks is the key for this hash table). I made my hash for the EV calculations use the full deck because I have included the suit-dependent Sp21 bonuses.

My splitting EV agrees exactly with k_c's on most values, but a few are off, presumably because I am using a "fixed strategy" after you split and resplit. For how people play, I figure this is a reasonable thing to do, but will consider changing this. However, resplitting takes a long time which I am working on trimming down. It's tricky because the hash table can't directly be used if there are remaining split hands to be played out.

My bonuses implementation agrees with the Sp21 basic strategy developed by Wizard of Odds and Kat Walker on everything I've checked, so I know I did those correctly.

What I will work on next:
  • Multi-card strategies for Sp21.
  • Bath-generate TD strategy as per your suggested route.
  • Hopefully index generation.

Now, regarding index generation, you said, "you need to use burn card probabilities" but you also said that it won't take into account how the count changes as you play. This is indeed how it should be done in a true brute force way, but what about a half-simmed sort of way? What I was planning on doing is to randomly generate count distributions, and determine the average EV of each decision at each count. This will be biased towards the middle of the shoe, but our index plays are estimates anyway, yes? And as each card is iterated through when you calculate the EV's, you can update the count to have the correct decision for each other play. But then again it becomes an iterated result, since the index plays would change after a new index play is added...
 

MGP

Well-Known Member
#39
Hi k_c :)

I'm not sure which values k_C has posted - again, the splits should match the TD values exactly from BJA3. I assume if k_c has TD values posted they will match those. The way you do the splits is correct. If you fix it based on total only, that's a TD strategy. If you play the first 2 cards CD and then use a TD strategy, that's a 2-Card (2C strategy) although Don makes weird exceptions in BJA3 but if you play a true 2-card strategy you do a little better than the BJA3 2-card values.

Calculating splits is actually very fast but they are a bit tricky to figure out. Cacarulo and I worked together and were the first to come up with exact, non-brute force values using CA's as far as I know. Stewart Ethier, in his book on the mathematics of gambling, which is a very thorough book (and has my burn card probs in it :) ) shows one way of calculating them, which he developed after I explained to him how I do it, although it's not amenable to calculating things like the Pontoon splits because it combines the probabilities of the hands with the ev's of the hands for each shoe state.

Katarina's book is by far the best on Spanish 21 and she knows more about it than anyone and is a great person. She was kind enough to help verify my CA's values for it and clarify the rules and we worked through the EORs together.

You should be able to handle all of the Spanish 21 rules with a CA including the Pontoon rules (http://wizardofodds.com/pontoon) however keep in mind that splits rules that involve busting are like variances and cannot be calculated exactly without brute-force, however in this case they can be calculated to an accuracy of 10-4.

"What I was planning on doing is to randomly generate count distributions, and determine the average EV of each decision at each count. "

Yes, the only way that makes sense to get counting plays is with sims and they can only be estimates without brute-force.

assume_R said:
Hi, MGP.

So I've already implemented the hash tables for different states as you suggested, for both dealer probability calculations (the number of cards from 0 to 10 with all faces lumped together is the key for this hash table) and EV calculations (the hand state and the deck state, with full suits and ranks is the key for this hash table). I made my hash for the EV calculations use the full deck because I have included the suit-dependent Sp21 bonuses.

My splitting EV agrees exactly with k_c's on most values, but a few are off, presumably because I am using a "fixed strategy" after you split and resplit. For how people play, I figure this is a reasonable thing to do, but will consider changing this. However, resplitting takes a long time which I am working on trimming down. It's tricky because the hash table can't directly be used if there are remaining split hands to be played out.

My bonuses implementation agrees with the Sp21 basic strategy developed by Wizard of Odds and Kat Walker on everything I've checked, so I know I did those correctly.

What I will work on next:
  • Multi-card strategies for Sp21.
  • Bath-generate TD strategy as per your suggested route.
  • Hopefully index generation.

Now, regarding index generation, you said, "you need to use burn card probabilities" but you also said that it won't take into account how the count changes as you play. This is indeed how it should be done in a true brute force way, but what about a half-simmed sort of way? What I was planning on doing is to randomly generate count distributions, and determine the average EV of each decision at each count. This will be biased towards the middle of the shoe, but our index plays are estimates anyway, yes? And as each card is iterated through when you calculate the EV's, you can update the count to have the correct decision for each other play. But then again it becomes an iterated result, since the index plays would change after a new index play is added...
 
Top