Software update with new split EVs

[k_c]

First, thanks very much to k_c for sharing your changes with me. Although I ended up taking a rather different approach, you (1) motivated me to revisit my resplitting algorithm, and (2) made the key observation that I had missed all this time about how to accurately compute resplits within the "framework" of my CA. (More on this shortly.)

The result is an update that-- I think-- now accurately computes CDZ- or CDP for splitting up to a maximum of 2, 3, or 4 hands. The new version 5.5 is available pre-built for Windows or via Bitbucket, at the two links at the top of this thread.

Also, thanks very much to MGP as well, for your recently available CA that proved very useful in testing. I encountered some interesting discrepancies between my results and those reported elsewhere, including k_c's changes to my code, as well as Cacarulo's tables from the old bjmath.com (http://www.bjmath.com/bjmath/ev/ev.htm (Archive copy)). Your CA was very handy for verifying some test cases, particularly a few very small shoes that I analyzed via brute-force.

k_c, I have not tracked down yet what is the root cause of the differences in your results, but I think I can identify where the issues occur. The problem seems to arise whenever there are more pair cards in the shoe than the maximum number of split hands. For example, splitting 10s for any number of decks, or splitting any pair with two or more decks, appears to generate different results.

(For anyone interested, many years ago I wrote up a rather terse description of how my algorithm now looks, at the link below. The idea was to aggregate the EV in terms of a relatively small number of parameterized EVs, conditioned on removing some number of pair cards and non-pair cards from the shoe. I never bothered to implement this, because it seemed difficult-- within my framework-- to compute the values conditioned on removing unspecified *non-pair* cards. But k_c's recent approach had the key new ingredient: that you can recursively evaluate those conditional EVs, eventually in terms of EVs with only *pair cards* removed, which is more easily do-able in my CA. The math involved is at:

http://sites.google.com/site/erfarmer/downloads/blackjack_split.pdf)

I look forward to seeing what you have done.

In the meantime I found the cause of the marginal errors in my algorithm. I think you are probably right about where they occur. In one place I had removed one too many pair cards.

I have not used this algorithm in years and when I used it I did not process all up cards at once. That is the hardest part for me in using it with your code because since the split function is recursive it's hard to keep track of what is removed.

I have downloaded and installed tortoiseHg but I still haven't been able to get my Bitbucket account to work. I uploaded my latest changes to my website if anyone wants to see them. These are direct links to download a zip file. At first glance it appears that the split EVs are now right.

(Dead link: http://www.bjstrat.net/Downloads/FarmerBJ_v53_VS2010.zip) _FarmerBJ_v53_VS2010.zip_
(Dead link: http://www.bjstrat.net/Downloads/FarmerBJ_v53_vcpp6.zip) _FarmerBJ_v53_vcpp6.zip_

My main problem right now is that I don't have a lot of time to do these kind of things.

 

[k_c]

Eric -

I downloaded version 5.5 of your program and it appears you now have splits working and in your own way.

One question - When choosing post-split strategy differs from pre-split can you describe what you do to make the post-split strategy consistent with using a fixed strategy and what the difference is between the 2 options?

(btw the changes I made to version 5.3 also work now.)

Thanks

 

[ericfarmer]

One question - When choosing post-split strategy differs from pre-split can you describe what you do to make the post-split strategy consistent with using a fixed strategy and what the difference is between the 2 options?

(I re-released an update I called 6.0; no functional changes from 5.5, but I did try to add to the documentation. Should have been 6.0/6.1, but I jumped the gun a bit.)

Your question is a good one. Perhaps MGP can jump in here as well, or at least correct me if I misspeak here; I recall some old bjmath.com discussions about the various kinds of strategies and convenient terminology for them, but I never saw how those conversations turned out. I'll try to explain the assumptions as I understand them.

First, note that CDP is *not* a fixed strategy... or rather, it depends on what you mean by "fixed." To clarify (and to review my understanding to make sure I'm not off in the weeds), let's start with CDZ-, which means the following:

1. Compute optimal composition-dependent strategy for all possible player hands assuming that splitting pairs is not allowed.
2. Evaluate E(split) for pairs, assuming that subsequent pairs are also re-split as often as possible, and that all split hands are played using the strategy computed in (1).
3. The final CDZ- strategy consists of (1), with the exception of splitting (and re-splitting) initial pairs for which E(split) from (2) is greater than all other options from (1).

In other words, the "Z" means that the only information available to the player when making a decision is the dealer's up card and the cards in the current hand of the round. The "-" simply means that the resulting strategy is not actually optimal subject to the constraints on what the player knows.

With CDP, the player is allowed to use just slightly more information. As with CDZ-, strategy is allowed to depend only on the dealer's up card, the cards in the current hand of the round... but also on the total number of pair cards removed/dealt in the round.

So CDP is still a "fixed" strategy, but it is "less fixed" in the sense that the player only needs to make the same decision every time he encounters the same larger set of conditions (up card, current hand, and number of pair cards).

Food for thought: it is not clear to me that CDP is actually realizable as a playing strategy. I mean this in principle, not just in the practical sense mentioned before of simply memorizing a larger number of strategy variations. That is, for example, when you are in the middle of playing out the first half of an initial split, you don't know at that point how many additional pair cards (and thus additional split hands) will result in the round. This may be my confusion about what is actually meant by CDP, so hopefully someone can comment.

 

[MGP]

Good summary.

It is playable because the strategy depends on how many paircards have been removed so far. In the middle of the hand you know how many pairs you've run into and so could theoretically adjust. That being said it's not realisitically playable the same way CD play is not realistic.

 

[k_c]

(I re-released an update I called 6.0; no functional changes from 5.5, but I did try to add to the documentation. Should have been 6.0/6.1, but I jumped the gun a bit.)

Your question is a good one. Perhaps MGP can jump in here as well, or at least correct me if I misspeak here; I recall some old bjmath.com discussions about the various kinds of strategies and convenient terminology for them, but I never saw how those conversations turned out. I'll try to explain the assumptions as I understand them.

First, note that CDP is *not* a fixed strategy... or rather, it depends on what you mean by "fixed." To clarify (and to review my understanding to make sure I'm not off in the weeds), let's start with CDZ-, which means the following:

1. Compute optimal composition-dependent strategy for all possible player hands assuming that splitting pairs is not allowed.
2. Evaluate E(split) for pairs, assuming that subsequent pairs are also re-split as often as possible, and that all split hands are played using the strategy computed in (1).
3. The final CDZ- strategy consists of (1), with the exception of splitting (and re-splitting) initial pairs for which E(split) from (2) is greater than all other options from (1).

In other words, the "Z" means that the only information available to the player when making a decision is the dealer's up card and the cards in the current hand of the round. The "-" simply means that the resulting strategy is not actually optimal subject to the constraints on what the player knows.

With CDP, the player is allowed to use just slightly more information. As with CDZ-, strategy is allowed to depend only on the dealer's up card, the cards in the current hand of the round... but also on the total number of pair cards removed/dealt in the round.

So CDP is still a "fixed" strategy, but it is "less fixed" in the sense that the player only needs to make the same decision every time he encounters the same larger set of conditions (up card, current hand, and number of pair cards).

Food for thought: it is not clear to me that CDP is actually realizable as a playing strategy. I mean this in principle, not just in the practical sense mentioned before of simply memorizing a larger number of strategy variations. That is, for example, when you are in the middle of playing out the first half of an initial split, you don't know at that point how many additional pair cards (and thus additional split hands) will result in the round. This may be my confusion about what is actually meant by CDP, so hopefully someone can comment.

Thanks. It seems at least CDZ- is clear enough.

One reason that I asked is because I know what I do and wonder how it contrasts to what others do.

I save both player and dealer hands in a binary search tree. Once an s17 and/or h17 dealer tree is created it remains in memory for the duration of the program. Player trees only remain in memory if a user of the program selects the option to compute using basic strategy. In that case all of the full shoe pre-split hands go into a tree[array by hand total]. That tree array is not destroyed unless there is a change of rules and not rebuilt again unless user again requests to compute using basic strategy. Any possible hand composition will always be in the basic strategy player tree, which defines how the hand will be played since the user has requested "basic strategy." (I know, I know - nobody uses CD basic strategy.)

When basic strategy is chosen the user has 2 choices of how to compute splits -

1) simply use the strategy in the full shoe player hand pre-split tree. I believe this is what is called CDZ- and what your program has computed in the past. This is a fixed strategy because all split hands are played the same.

2) compute using post split strategy. In this case I build another full shoe tree with the hands from the first split hand, played optimally. All of the subsequent split hands are then played with this same strategy. This is also a fixed strategy because all split hands are played the same.

If a user of the program has entered a less than full shoe composition and has chosen basic strategy as the compute mode then the full shoe "basic strategy" is applied to that composition and splits are computed according to user's choice getting strategy from the appropriate tree.

If a user chooses to compute optimally then all pre-split hands are computed optimally for whatever shoe composition is entered. Splits are computed by building a temporary split (hand 1) tree which plays the first hand optimally for whatever shoe composition is entered and the subsequent split hands are played according to that strategy. This is also a fixed strategy because all split hands are played the same.

So I am always using a fixed strategy for splits.

 

[ericfarmer]

2) compute using post split strategy. In this case I build another full shoe tree with the hands from the first split hand, played optimally. All of the subsequent split hands are then played with this same strategy. This is also a fixed strategy because all split hands are played the same.

I like this idea. You're right, this strategy is a function of the up card, the cards in the current hand, and whether the hand is after a split or not; all post-split hands play the same strategy. To make sure I understand exactly what you're doing, I made some small changes to my code and went looking for specific situations where we would actually come up with different answers. I didn't have to look far.

Consider 1D, S17, DAS, (re)splitting a pair of 2s against a dealer 7. I get a split EV of 1.608853999%; do you get 1.598696873% in the same situation? (Edit: I updated the situation and values to address a bug in my initial test code.)

The first post-split hand that I found that starts from the above split is 2-5-8-A. With that hard 16, optimal strategy with one additional 2 removed is to hit, which is what you then apply across the board, right? But with two 2s removed, optimal strategy is to stand. I apply these variations, yielding the different EV above.

I need to think about this some more. I admit I am still not "getting it," since I am still suspicious of my results for three reasons:

1. CDP is using strictly more information than k_c's strategy; that is, CDP "knows" not just that the hand is post-split, but how many pair cards have been split so far. So why is the CDP split EV less than k_c's in the same situation above?

2. I think I understand MGP's clarification of what CDP really means. But intuitively it seems like my algorithm must not be computing CDP, then(see (3) below)... and yet I have been unable to find a shoe, rules, and hand where our results differ. If anyone can find one let me know.

3. The reason I think my algorithm doesn't quite calculate CDP is that I think it admits strategy variations as a function of the number of pair cards that "will" be split in the round, not just that have appeared so far. I am basing this on the way that I recursively evaluate EV[X;a,b] (recall this notation from the paper linked earlier as well as the originating bjmath.com discussions) in terms of EV[X;a,b-1] and EV[X;a+1,b-1]; this last term is an EV based on strategy possibly varying with one more pair card removed.

Now that I write that sentence, perhaps for my results to differ from MGP's CDP, the strategy for a given hand must be "non-monotonic" as a function of the number of additional pair cards removed. That is, for example, if you should hit with one pair card removed, and stand with two removed, then unless you should "switch back to" hitting with any of three or more removed, then I would expect my results to still match MGP's. Otherwise they would be different; I will check this out...

 

[FLASH1296]

There is actually a game called "Farmer's 21",
a simple form of blackjack geared to being a friendly game;
and certainly not a casino game.

I have a computerized version from long ago (from Sweden)

Rules are strange enough to be sure:

You play before the dealer gets any cards.
You continue until you stand.
There are no premiums except an unbusted
5 card hand is an automatic 3-1 winner.
No splits or doubles or BJ's
Aces are only ONE, not eleven.
Jacks are 11,
Queens are 12
Kings are 13

When you stand the dealer takes cards,
and must hit on 15 and stand on 16.

 

[ericfarmer]

Consider 1D, S17, DAS, (re)splitting a pair of 2s against a dealer 7. I get a split EV of 1.608853999%; do you get 1.598696873% in the same situation? (Edit: I updated the situation and values to address a bug in my initial test code.)

The first post-split hand that I found that starts from the above split is 2-5-8-A. With that hard 16, optimal strategy with one additional 2 removed is to hit, which is what you then apply across the board, right? But with two 2s removed, optimal strategy is to stand. I apply these variations, yielding the different EV above.

1. CDP is using strictly more information than k_c's strategy; that is, CDP "knows" not just that the hand is post-split, but how many pair cards have been split so far. So why is the CDP split EV less than k_c's in the same situation above?

As noted in the edit, I had a bug in my initial test code. Fixing that fixed the disturbing inequality reversal here.

Now that I write that sentence, perhaps for my results to differ from MGP's CDP, the strategy for a given hand must be "non-monotonic" as a function of the number of additional pair cards removed. That is, for example, if you should hit with one pair card removed, and stand with two removed, then unless you should "switch back to" hitting with any of three or more removed, then I would expect my results to still match MGP's. Otherwise they would be different; I will check this out...

Interestingly, I was unable to find such a pathological "non-monotonic" strategy situation. That is, in every shoe I tested, strategy for a post-split hand never changed, say, from hit to stand then back to hit as the number of additional pair cards increased from 1 to 2 to 3. Granted, I only looked at full shoes-- 1, 2, and 4 decks. I didn't look beyond that since I expected strategy variations to diminish as the shoe gets larger. And I didn't look at subsets smaller than a single deck since such a systematic search would take some more work.

So unfortunately, I don't have any definite evidence yet for the claim that my algorithm is suspect; that is, that it could produce values different from, say, MGP's CDP values.

At any rate, I like k_c's additional option for post-split strategy. Any suggestions for what to call it? CDP1, maybe?

 

[MGP]

I need to think about this some more. I admit I am still not "getting it," since I am still suspicious of my results for three reasons:

2. I think I understand MGP's clarification of what CDP really means. But intuitively it seems like my algorithm must not be computing CDP, then(see (3) below)... and yet I have been unable to find a shoe, rules, and hand where our results differ. If anyone can find one let me know.

3. The reason I think my algorithm doesn't quite calculate CDP is that I think it admits strategy variations as a function of the number of pair cards that "will" be split in the round, not just that have appeared so far. I am basing this on the way that I recursively evaluate EV[X;a,b]

Just to clarify, I don't calculate splits recursively so I know mine is actually CDP. I also have a CDPN calculation that not only takes into account the number of paircards played but also the number of Non-paircards played. I don't know enough about recursive calcs to understand why you think they shouldn't match.

 

[k_c]

As noted in the edit, I had a bug in my initial test code. Fixing that fixed the disturbing inequality reversal here.



Interestingly, I was unable to find such a pathological "non-monotonic" strategy situation. That is, in every shoe I tested, strategy for a post-split hand never changed, say, from hit to stand then back to hit as the number of additional pair cards increased from 1 to 2 to 3. Granted, I only looked at full shoes-- 1, 2, and 4 decks. I didn't look beyond that since I expected strategy variations to diminish as the shoe gets larger. And I didn't look at subsets smaller than a single deck since such a systematic search would take some more work.

So unfortunately, I don't have any definite evidence yet for the claim that my algorithm is suspect; that is, that it could produce values different from, say, MGP's CDP values.

At any rate, I like k_c's additional option for post-split strategy. Any suggestions for what to call it? CDP1, maybe?

Eric, this is what I get for 2-2 v 7 s17, single deck DAS

Use optimal strategy of first hand for all splits
SPL1 0.0063296898639950416
SPL2 0.015445169178526293
SPL3 0.015986968729175405

Use pre-split strategy for all splits
SPL1 0.0051051966492733358
SPL2 0.013727697735311283
SPL3 0.014220917573631663

A place you might look to get a more optimal EV is when a pair hand is drawn but not split. In the case of resplits when a pair hand is drawn it isn't necessary to commit to a strategy at that point because the hand is resplit. Only when it isn't resplit is it necessary to determine a strategy, so at that point more pair cards will have been removed.

What I do is to play the unsplit pair hand the same as if it wouldn't have been split on the first hand so it's possible that it should be played differently for resplits. This ensures that I'm using a fixed strategy. I really don't know if it may be possible to come up with a more optimal fixed strategy for resplits.

I'm not sure how more optimal methods would work, but that's as far as I've gone with it.

 

[ericfarmer]

Eric, this is what I get for 2-2 v 7 s17, single deck DAS

Use optimal strategy of first hand for all splits
SPL1 0.0063296898639950416
SPL2 0.015445169178526293
SPL3 0.015986968729175405

Use pre-split strategy for all splits
SPL1 0.0051051966492733358
SPL2 0.013727697735311283
SPL3 0.014220917573631663

Great! I can reproduce your numbers, and I updated my code to allow this as an option (and next to CDZ-, I think I like this as a most sensible next increment in complexity, with CDP following after).

For reference, the link is:
https://sites.google.com/site/erfarmer/downloads

And the Mercurial repository is at:

hg clone http://bitbucket.org/possiblywrong/blackjack

(Ken, I wasn't sure from your earlier mention about helping with code sharing if you were interested in hosting this here or not. I have no problem with that if that's what you want to do, just let me know.)

 

[ericfarmer]

Just to clarify, I don't calculate splits recursively so I know mine is actually CDP. I also have a CDPN calculation that not only takes into account the number of paircards played but also the number of Non-paircards played. I don't know enough about recursive calcs to understand why you think they shouldn't match.

I added to my earlier write-up on pair splitting to try to explain in more detail what my algorithm does. It's at:
http://sites.google.com/site/erfarmer/downloads/blackjack_split.pdf

I think the key observation for my current questions is the fact that I pre-compute, ahead of time, EV(X;a,0) and EV(P;a,0) for all necessary values of a (where a indicates the number of additional pair cards removed from the shoe; see the paper for explanation of notation). For each particular number a of pair cards removed, computing EV(X;a,0) and EV(P;a,0) are easy... but they each depend on a choice of playing strategy.

For CDZ-, the strategy is fixed for all a, and there is no problem. But for CDP, I make EV-optimizing decisions for the "tree" of possible completions of hands with a=0; then I make a new set of EV-optimizing decisions, with possibly different strategy, for the tree of hands with a=1, then again for a=2, etc. (BTW, for CDP1, as suggested by k_c, I simply fix the strategy for a=0 and apply it for all of the other a>0.)

Now when computing the overall expected return for the initial split, using the equation in the paper (the one summing over indices h and k), the various EV(X;a,b) and EV(N;a,b) involve removing some b>0 non-pair cards. The final section of the paper is the new part, and describes simple recurrences that can compute these EV(X;a,b) and EV(N;a,b) in terms of values with progressively smaller values for b, until eventually we have just the EV(X;a,0) and EV(P;a,0) values that we pre-computed.

The potential problem that I have been sticking on, though, is that, for example, when I recursively expand EV(N;2,2) in terms of EV(X;2,0), EV(X;3,0), and EV(X;4,0) (as well as the corresponding EV(P;#,0)), each of those individual EV(X) values assumes a potentially different playing strategy.

But as usual, it's good to simply write out my thoughts, because as I read this now I think there is not necessarily a problem with this at all, since the recurrence relation naturally expresses the fact that each of those different EV(X;a,0) situations will be encountered *chronologically as the value of a increases*, and so it's ok that the strategy varies with a.

Right?

 

[FLASH1296]

SD with DAS ?

Well, I guess that that is of some academic interest.

 

[assume_R]

SD with DAS ?

Well, I guess that that is of some academic interest.

Only used to validate an algorithm. Single deck is better for combinatorial analysis (CA) validation because the CA result from a 6 deck or 8 deck shoe might be extremely similar, while for single deck, every card that is added to the hand significantly changes the EV. That's why we've used single decks to compare check our CA algorithms. In addition, splits are notoriously tricky to get correct (especially in a timely manner), and to make absolutely sure we are doing it correctly, allowing one to double after a split will indeed change the EV. If we can agree on SD DAS, we know with a fair amount of confidence that our algorithm is extendable to other situations.

 

[MangoJ]

Only used to validate an algorithm. Single deck is better for combinatorial analysis (CA) validation because the CA result from a 6 deck or 8 deck shoe might be extremely similar, while for single deck, every card that is added to the hand significantly changes the EV. That's why we've used single decks to compare check our CA algorithms. In addition, splits are notoriously tricky to get correct (especially in a timely manner), and to make absolutely sure we are doing it correctly, allowing one to double after a split will indeed change the EV. If we can agree on SD DAS, we know with a fair amount of confidence that our algorithm is extendable to other situations.

How about using Quarter Deck as a benchmark ? One could evaluate split (and resplitting) tens by brute force, and test the CA algorithm against it.

 

[ericfarmer]

How about using Quarter Deck as a benchmark ? One could evaluate split (and resplitting) tens by brute force, and test the CA algorithm against it.

There are a lot of "nice" small shoes like this. One particularly handy one that I used recently to test my splitting algorithm was a shoe with nothing but 8s, 9s, and 10s. With a small number of them (e.g., just 5 or 6 each), brute force evaluation of all possible arrangements is feasible. And this particular subset has the nice property that splitting 9s vs. dealer 8 may be implemented very simply: there is no hitting, just splitting and resplitting, followed by a "showdown" of two-card hands with the highest total winning.

(k_c, I re-implemented this simpler game with this small shoe in Mathematica to test, symbolically as a function of the EV[X;a,0] and EV[P;a,0], your initial modifications to my code, to see why our results were differing.)

 

[iCountNTrack]

There are a lot of "nice" small shoes like this. One particularly handy one that I used recently to test my splitting algorithm was a shoe with nothing but 8s, 9s, and 10s. With a small number of them (e.g., just 5 or 6 each), brute force evaluation of all possible arrangements is feasible. And this particular subset has the nice property that splitting 9s vs. dealer 8 may be implemented very simply: there is no hitting, just splitting and resplitting, followed by a "showdown" of two-card hands with the highest total winning.

(k_c, I re-implemented this simpler game with this small shoe in Mathematica to test, symbolically as a function of the EV[X;a,0] and EV[P;a,0], your initial modifications to my code, to see why our results were differing.)

That is a very interesting deck(5 8's, 5 9's, 5, 10's) , nice thing about it, my code zaps through it in 0.05 seconds. the following are results for 1,2,3 splits using optimal post-split strategy.

1 split

******************ChemMeister iCountNTrack*******************
**************Blackjack Combinatorial Analyzer v 0.5**************

player's Hand  9,9
dealer's upCard  8
 
player's probabilities for standing
p_-1 = 0
p_0 = 0.416667
p_+1= 0.583333
p_+1.5 = 0
EV for standing= 0.583333 ± 0.493007
 
player's probabilities for doubling
p_-2 = 1
p_0 = 0
p_+2= 0
EV for doubling= -2 ± 0
 
player's probabilities for hitting
p_-1 = 1
p_0 = 0
p_+1= 0
EV for hitting= -1 ± 0
 
player's probabilities for splitting
p_-4 = 0
p_-3 = 0
p_-2 = 0.0454545
p_-1 = 0.0909091
p_0 = 0.171212
p_+1= 0.218182
p_+2 = 0.474242
p_+3 = 0
p_+4 = 0
EV for splitting= 0.984848 ± 1.19078

2 splits

******************ChemMeister iCountNTrack*******************
**************Blackjack Combinatorial Analyzer v 0.5**************
 
player's Hand  9,9
dealer's upCard  8
 
player's probabilities for standing
p_-1 = 0
p_0 = 0.416667
p_+1= 0.583333
p_+1.5 = 0
EV for standing= 0.583333 ± 0.493007
 
player's probabilities for doubling
p_-2 = 1
p_0 = 0
p_+2= 0
EV for doubling= -2 ± 0
 
player's probabilities for hitting
p_-1 = 1
p_0 = 0
p_+1= 0
EV for hitting= -1 ± 0
 
player's probabilities for splitting
p_-6 = 0
p_-5 = 0
p_-4 = 0
p_-3 = 0.00757576
p_-2 = 0.0643939
p_-1 = 0.0505051
p_0 = 0.20202
p_+1= 0.167929
p_+2 = 0.322475
p_+3 = 0.185101
p_+4 = 0
p_+5 = 0
p_+6 = 0
EV for splitting= 1.16616 ± 1.4629

3 splits

******************ChemMeister iCountNTrack*******************
**************Blackjack Combinatorial Analyzer v 0.5************** 
player's Hand  9,9
dealer's upCard  8
 
player's probabilities for standing
p_-1 = 0
p_0 = 0.416667
p_+1= 0.583333
p_+1.5 = 0
EV for standing= 0.583333 ± 0.493007
 
player's probabilities for doubling
p_-2 = 1
p_0 = 0
p_+2= 0
EV for doubling= -2 ± 0
 
player's probabilities for hitting
p_-1 = 1
p_0 = 0
p_+1= 0
EV for hitting= -1 ± 0
 
player's probabilities for splitting
p_-8 = 0
p_-7 = 0
p_-6 = 0
p_-5 = 0
p_-4 = 0.00111833
p_-3 = 0.00649351
p_-2 = 0.0689394
p_-1 = 0.0348124
p_0 = 0.220238
p_+1= 0.141991
p_+2 = 0.386291
p_+3 = 0.0243506
p_+4 = 0.115765
p_+5 = 0
p_+6 = 0
p_+7 = 0
p_+8 = 0
EV for splitting= 1.25404 ± 1.60401

 

[ericfarmer]

That is a very interesting deck(5 8's, 5 9's, 5, 10's) , nice thing about it, my code zaps through it in 0.05 seconds. the following are results for 1,2,3 splits using optimal post-split strategy.

(snip)

3 splits

******************ChemMeister iCountNTrack*******************
**************Blackjack Combinatorial Analyzer v 0.5************** 
player's Hand  9,9
dealer's upCard  8
 
player's probabilities for standing
p_-1 = 0
p_0 = 0.416667
p_+1= 0.583333
p_+1.5 = 0
EV for standing= 0.583333 ± 0.493007
 
player's probabilities for doubling
p_-2 = 1
p_0 = 0
p_+2= 0
EV for doubling= -2 ± 0
 
player's probabilities for hitting
p_-1 = 1
p_0 = 0
p_+1= 0
EV for hitting= -1 ± 0
 
player's probabilities for splitting
p_-8 = 0
p_-7 = 0
p_-6 = 0
p_-5 = 0
p_-4 = 0.00111833
p_-3 = 0.00649351
p_-2 = 0.0689394
p_-1 = 0.0348124
p_0 = 0.220238
p_+1= 0.141991
p_+2 = 0.386291
p_+3 = 0.0243506
p_+4 = 0.115765
p_+5 = 0
p_+6 = 0
p_+7 = 0
p_+8 = 0
EV for splitting= 1.25404 ± 1.60401

Hmmm. Thanks for running this, because I get slightly different results, so the more sanity checking, the better. I can reproduce your results for SPL1 and SPL2, but for SPL3 I get an EV for splitting of 247/198 = 1.247474. I get this value both with my strategy.exe calculator, where it is "actually" analyzing blackjack, as well as with my faked-up Mathematica implementation of the no-hit showdown game that I described earlier.

Following is my breakdown of the splitting outcomes for each of the 27,720 arrangements of the cards in the shoe (after removing the initial pair and dealer up card):

p_-4 = 25/27720 = 0.000901876
p_-3 = 280/27720 = 0.010101
p_-2 = 1660/27720 = 0.0598846
p_-1 = 1680/27720 = 0.0606061
p_0 = 5105/27720 = 0.184163
p_1 = 4930/27720 = 0.17785
p_2 = 8764/27720 = 0.316162
p_3 = 3042/27720 = 0.10974
p_4 = 2234/27720 = 0.0805916

I'm not sure where the problem is yet. I am assuming that the player always resplits whenever possible; maybe that is the cause of the difference? If it is helpful for comparison, I can pm a zipfile with the actual shoe arrangements and my itemization of the outcomes.

 

[iCountNTrack]

Hmmm. Thanks for running this, because I get slightly different results, so the more sanity checking, the better. I can reproduce your results for SPL1 and SPL2, but for SPL3 I get an EV for splitting of 247/198 = 1.247474. I get this value both with my strategy.exe calculator, where it is "actually" analyzing blackjack, as well as with my faked-up Mathematica implementation of the no-hit showdown game that I described earlier.

Following is my breakdown of the splitting outcomes for each of the 27,720 arrangements of the cards in the shoe (after removing the initial pair and dealer up card):

p_-4 = 25/27720 = 0.000901876
p_-3 = 280/27720 = 0.010101
p_-2 = 1660/27720 = 0.0598846
p_-1 = 1680/27720 = 0.0606061
p_0 = 5105/27720 = 0.184163
p_1 = 4930/27720 = 0.17785
p_2 = 8764/27720 = 0.316162
p_3 = 3042/27720 = 0.10974
p_4 = 2234/27720 = 0.0805916

I'm not sure where the problem is yet. I am assuming that the player always resplits whenever possible; maybe that is the cause of the difference? If it is helpful for comparison, I can pm a zipfile with the actual shoe arrangements and my itemization of the outcomes.

I dont quite understand your setup, are you calculating split EVs using optimal post-split strategies. I use optimal post-split EVs.
This is a download link for the program, you can tinker with it if you would like

http://code.google.com/p/blackjack-combinatorial-analyzer/downloads/list

 

[ericfarmer]

I dont quite understand your setup, are you calculating split EVs using optimal post-split strategies. I use optimal post-split EVs.
This is a download link for the program, you can tinker with it if you would like

http://code.google.com/p/blackjack-combinatorial-analyzer/downloads/list

Thanks, I will take a closer look tonight. My only implemented options are CDZ-, CDP1, and CDP... all of which involve splitting and re-splitting at every opportunity. Since in this little shoe the only player options are to stand or split, our differences suggest that it must be the case that there exists some situation with three split hands and another drawn 9, where it is optimal to not re-split again (like I do) and instead stand on the 18.

It would take a bit of work for me to verify this; is this a situation you can find more easily using your algorithm?