Eric Farmer code: wrong split EV estimates ?

[iCountNTrack]

This is correct, but not much of a "problem" in terms of concept, but only from computational effort and time. You "just" cycle recursively (or by any other method) through all first hands, and for evaluation of "stand" you don't convolute against dealer probabilities, but you just cycle then through the next hand (for each standing first hand, taking into account cards consumed by first hand). If the computational effort for a single hand (with no split allowed) is N, then for no resplit (split1) it is N². Likewise for any deeper levelit is N³ (split2) and N^4 (split3).

This is the thing to do if you want optimum play EV. With proper caching technique not only on dealer, but also on player hands, the deepest hand can be precomputated, which reduces the problem to N³, which is doable nowadays.

I don't think optimal strategy is in any way ill-defined. Sure it is costly to compute, but far from impossible.

Please don't put words in my mouth that i didn't say. I did clearly describe with an example how post-split optimal play works. After all my CA does calculate split evs using post-split optimal strategy(did you even read my posts !
My ill-defined term was in reference to reporting ONE value for split2 and split3, that is because like i have shown in the example there are gazillion different values because of the gazillion different compositions on split hand number one and split hand number 2. This is not the case for FIXED strategies.

Player's Hand             Dealer Upcard
     8,8			  9

cannot determine ONE split2 value using post-split optimum strategy

//*******************************************************************************

		Player First Split Hand             Player Second Split Hand
		         8,2,10				        8,8

can report ONE split2 value using post-split optimum strategy

 

[London Colin]

If need be you can just run the CA three times. Once with the rules set to allow no resplitting, once set to allow 1 resplit, and once set to allow 2 resplits.

You'll get three different answers. Those are the SPL1, SPL2, and SPL3 EVs we are talking about. (At least that is my understanding, and what I tried to convey previously. I could of course be wrong. )

Or it may be possible to extract intermediate values from a single run. I guess it depends on the precise nature of the algorithm being used.

 

[iCountNTrack]

If need be you can just run the CA three times. Once with the rules set to allow no resplitting, once set to allow 1 resplit, and once set to allow 2 resplits.

You'll get three different answers. Those are the SPL1, SPL2, and SPL3 EVs we are talking about. (At least that is my understanding, and what I tried to convey previously. I could of course be wrong. )

Or it may be possible to extract intermediate values from a single run. I guess it depends on the precise nature of the algorithm being used.

One more attempt, let's focus on SPL2. When you are doing optimum post-split strategy you cannot report one value for SPL2 because you have many many cases.

Case 1
Dealer 9
First Split hand 8,1
Second split Hand 8,8 , EV of splitting this hand i.e SPL2 calculated optimally would have to include cards seen on first split hand (8,1)

Case 2
Dealer 9
First Split hand 8,2,1
Second split Hand 8,8 , EV of splitting this hand i.e SPL2 calculated optimally would have to include cards seen on first split hand (8,2,1)

...

Case 3

Dealer 9
First Split hand 8,7,10
Second split Hand 8,8 , EV of splitting this hand i.e SPL2 calculated optimally would have to include cards seen on first split hand (8,7,10)

....

Clearly the EV of splitting (SPL2) in each case will be different because first split hand has a different composition.


so when i start out with

8,8 vs 9 I CANNOT report one value for SPL2 because i would have many many cases like the samples ones listed in the above each with a different composition on the other split hand thus each with a different EV.
The algorithm would have nothing to do with this because that an intrinsic nature of post-split optimal strategy (taking into account ALL the cards seen and finding the optimal decision on any of the split hands)

 

[London Colin]

I'm talking about the overall EV of splitting the initial pair, under three different rules.

I'm suggesting that the definition of the SPLn EV may be something like -

"The overall EV from splitting at least once and no more than n times".

I don't know how else to put it.

 

[iCountNTrack]

I'm talking about the overall EV of splitting the initial pair, under three different rules.

I'm suggesting that the definition of the SPLn EV may be something like -

"The overall EV from splitting at least once and no more than n times".

I don't know how else to put it.

You are talking about the rules??? OMG lol, i thought you are talking about something totally different.
But in any case to answer your question the overall EV of the round for splitting at least once would be calculated the same way

If the player is only allowed to split once, after the first the split, the collection of optimal decision on the child sequences of the split hands can only be a hit, stand, or double (on 2 cards, or any number of cards)

If the player is only allowed to split 2, after the first split the collection of optimal decision on the child sequences of the split hands can only be a hit, stand, or double (on 2 cards, or any number of cards) and one more split.

If the player is only allowed to split 2, after the first split the collection of optimal decision on the child sequences of the split hands can only be a hit, stand, or double (on 2 cards, or any number of cards) and two more splits.

This diagram would better explain,

at each row the decision with highest EV (optimal includes all seen cards) is chosen.

 

[London Colin]

You are talking about the rules??? OMG lol, i thought you are talking about something totally different.

I'm fairly sure that's all any of us have been talking about (except for your good self) from the point where k_c posted this - [post]239252[/post]

The point is that your initial comment that you didn't include SPL2 and SPL3 EVs in the output of your CA seemed to me to misunderstand what people mean by those terms. I may be wrong, but I don't think any CA will be reporting on the EV of a notional 2nd or 3rd hand in a split, they report the overall EVs of repeated splitting up to some limit.

And although that limit will generally be imposed from without, by the rules of the casino, there is no harm is posing questions like "what would my EV be if I restricted myself to only one split", and so on.

But the prospect of different strategies, possibly declining some resplits in favour of higher-EV alternatives, does make things a little messy. Hence the tentative nature of my definition above. It becomes not so much "repeated resplitting" as "repeated exercising of a set of options which includes resplitting".

But in any case to answer your question the overall EV of the round for splitting at least once would be calculated the same way [...]

I didn't really have a question; I got the gist of what you were describing. I was just struggling to find a way to make it plain that it didn't contradict anything I was describing! Glad we got there in the end. :grin:

 

[k_c]

See above

I think you can define spl1, spl2, spl3, ....., spln even for optimal splits.

spl1 means that you make each decision optimally. If you draw a pair card you must play the pair hand without splitting, since there are no more splits allowed. So if you're splitting 2-2 if another 2 is drawn it must be played optimally as 2-2 = 4. If more than 1 split was allowed then 2-2 would be split if and only if there were splits remaining when the 2-2 is drawn.

To get a valid EV for spl1 you cannot allow any resplitting.

To get a valid EV for spl2 you must go through all decisions optimally, resplitting the 2-2 when appropriate and treating it as 2-2 = 4 when appropriate. spl2 allows for 1 resplit and no more.

spl3 would be still harder. spl3 allows for 2 resplits and no more.
.
.
spln allows for n-1 resplits and no more.

 

[iCountNTrack]

I'm fairly sure that's all any of us have been talking about (except for your good self) from the point where k_c posted this - [post]239252[/post]

The point is that your initial comment that you didn't include SPL2 and SPL3 EVs in the output of your CA seemed to me to misunderstand what people mean by those terms. I may be wrong, but I don't think any CA will be reporting on the EV of a notional 2nd or 3rd hand in a split, they report the overall EVs of repeated splitting up to some limit.

And although that limit will generally be imposed from without, by the rules of the casino, there is no harm is posing questions like "what would my EV be if I restricted myself to only one split", and so on.

But the prospect of different strategies, possibly declining some resplits in favour of higher-EV alternatives, does make things a little messy. Hence the tentative nature of my definition above. It becomes not so much "repeated resplitting" as "repeated exercising of a set of options which includes resplitting".



I didn't really have a question; I got the gist of what you were describing. I was just struggling to find a way to make it plain that it didn't contradict anything I was describing! Glad we got there in the end. :grin:

We need to come up with a unified glossary of terms :grin:

 

[iCountNTrack]

I think you can define spl1, spl2, spl3, ....., spln even for optimal splits.

spl1 means that you make each decision optimally. If you draw a pair card you must play the pair hand without splitting, since there are no more splits allowed. So if you're splitting 2-2 if another 2 is drawn it must be played optimally as 2-2 = 4. If more than 1 split was allowed then 2-2 would be split if and only if there were splits remaining when the 2-2 is drawn.

To get a valid EV for spl1 you cannot allow any resplitting.

To get a valid EV for spl2 you must go through all decisions optimally, resplitting the 2-2 when appropriate and treating it as 2-2 = 4 when appropriate. spl2 allows for 1 resplit and no more.

spl3 would be still harder. spl3 allows for 2 resplits and no more.
.
.
spln allows for n-1 resplits and no more.

see all my subsequent posts :grin:

 

[k_c]

see all my subsequent posts :grin:

To be clear, definitions of spl1, spl2, spl3, ...., spln have nothing to do with the mechancis of how splits are computed.

spl1 means no resplitting is allowed.
spl2 means one resplit is allowed.
spl3 means two resplits are allowed.
.
.
spln means n-1 resplits are allowed

spl2 to spln come with the associated problem of drawing a splittable hand when allowed splits are exhausted, in which case the hand must be played as p-p = 2*p rather than split. This is a problem with a recursive algorithm. A recursive algorithm doesn't address this problem without some tweaking.

It doesn't matter how EV is computed as long as it is correct. A correct EV could be optimal or sub optimal.

spl1 is the EV for splitting once, no resplitting. There are always just 2 hands.
spl2 is the EV for splitting to up to 3 hands. There may be 2, or 3 hands depending upon what is drawn. There can be no more than 3 hands.
spl3 is the EV for splitting to up to 4 hands. There may be 2, 3, or 4 hands depending upon what is drawn. There can be no more than 4 hands.
.
.
spln is the EV for splitting to up to (n+1) hands. There may be 2, 3, ..., (n+1) hands depending upon what is drawn. There can be no more than (n+1) hands.

If an algorithm allows resplits to compute a spl1 EV then it is incorrect. spl1 by definition allows no resplits. That is all I'm saying. I have no idea what went into the EV you posted but it wasn't clear if resplits were allowed in computing a spl1 EV.

 

[iCountNTrack]

To be clear, definitions of spl1, spl2, spl3, ...., spln have nothing to do with the mechancis of how splits are computed.

spl1 means no resplitting is allowed.
spl2 means one resplit is allowed.
spl3 means two resplits are allowed.
.
.
spln means n-1 resplits are allowed

spl2 to spln come with the associated problem of drawing a splittable hand when allowed splits are exhausted, in which case the hand must be played as p-p = 2*p rather than split. This is a problem with a recursive algorithm. A recursive algorithm doesn't address this problem without some tweaking.

It doesn't matter how EV is computed as long as it is correct. A correct EV could be optimal or sub optimal.

spl1 is the EV for splitting once, no resplitting. There are always just 2 hands.
spl2 is the EV for splitting to up to 3 hands. There may be 2, or 3 hands depending upon what is drawn. There can be no more than 3 hands.
spl3 is the EV for splitting to up to 4 hands. There may be 2, 3, or 4 hands depending upon what is drawn. There can be no more than 4 hands.
.
.
spln is the EV for splitting to up to (n+1) hands. There may be 2, 3, ..., (n+1) hands depending upon what is drawn. There can be no more than (n+1) hands.

If an algorithm allows resplits to compute a spl1 EV then it is incorrect. spl1 by definition allows no resplits. That is all I'm saying. I have no idea what went into the EV you posted but it wasn't clear if resplits were allowed in computing a spl1 EV.

It was just a difference in terminology, i thought SPL1, SPL2, SPL3 meant the actions of splitting once, twice and three times. Not the actual rules. But now i understand they are actually referring to the rules. The value i had posted included the rule of 3 allowed splits.

 

[k_c]

It was just a difference in terminology, i thought SPL1, SPL2, SPL3 meant the actions of splitting once, twice and three times. Not the actual rules. But now i understand they are actually referring to the rules. The value i had posted included the rule of 3 allowed splits.

MGP
My CA for CDPN gives a net EV 0.424280222269252 for 9,9 vs 6 1D S17 DAS SPL3. I'm not sure what you mean by "the first split". I'm curious what you get for a net EV. I'm guessing the CDPN strategy will capture most of it.

In that case your EV is not optimal. Above is quote from MGP. His fixed strategy EV is slightly more optimal than mine but in this case there is no difference.

My EV, 0.42428022226925299

If you really want to get optimal EV I would suggest that you work on 1 split. That seems plenty difficult enough to me. But maybe there's just a minor change that needs to be made. Who knows?

 

[MGP]

Thinking about it more, there shouldn't be any strategy deviations for 9,9 vs 6 so there's got to be a bug in your program.

 

[assume_R]

My EV, 0.42428022226925299

I concur.

 

[ericfarmer]

Hi,

I'm not sure how Eric's code works...

Just checking into the conversation, after stumbling across this forum. It's been a while, but I can try to explain or answer any questions if I can. I'm just enjoying seeing people get some use out of the code after all these years!

While I'm at it, the latest 5.2 code is available at a few locations, among them my sparse web site (really just a hosting companion to my blog):

https://sites.google.com/site/erfarmer/downloads

In order to at least test which value is off, I did a simulation of 500.000 splits, and the first hand got an EV of 26.53% +/- 0.37% (actually half of that). The second hand played afterwards gets an EV of 27.60% +/- 0.37%. The second hand EV is higher, as more cards are already known.

I think there are actually two potential issues here. One has already been pointed out by Colin, that my original code assumes that playing strategy *after* a split is the same as the (previously-computed) strategy that would be used if the same hand were encountered *without* splitting.

But your simulation test described above suggests something different might be wrong. Assuming no resplits (i.e., just two halves of a split), and assuming that we use the same *fixed* strategy on both halves (as my code does), then the expected values of the two individual halves of the split should be the *same*. Your test results, and the comment that "more cards are already known," suggest that you are playing different strategy for the first half than the right half.

(Note that Colin's point was that you and I were assuming different, but still fixed, strategies.)

Eric

 

[ericfarmer]

London, Eric would be the first to admit he uses an approximation...

(snip)

There are more shoe states than just these for splits > SPL1 which is why this alone won't work. There was a post about bringing it all together that elucidates the various shoe states you need. It turns out Eric's shoe state combinations matched the brute force calculation he did but both sets give the correct values.

Yep. If it's helpful, following is a description of the (lack of) accuracy of my code in various situations:

1. With no resplits allowed, my code provides exact values... but for what Steve Jacobs referred to as "CDZ-" strategy (composition-dependent zero-memory, pre-split). This is the "human-friendly" strategy described elsewhere in this thread. As Colin points out, it is reasonably straightforward to tweak the code to compute CDZ instead (where we still fix the post-split strategy, but allow it to differ from pre-split).

2. With resplits allowed, my code is an approximation, and not, IMO, a great one at that. It only accurately computes the probabilities (weights) of the various numbers of split hands; the expected values of those individual hands/situations is approximated.

As MGP mentions, I tried to roll this up into one document that describes the split calculations, in a form that is generalizable to both finite decks that you care about here, but also to infinite decks. See the blackjack_split.pdf link at my site:

https://sites.google.com/site/erfarmer/downloads

Hope this helps,
Eric

 

[ericfarmer]

One of the hardest things I found to understand about the code is the data structure used to hold every possible player hand. The key point to understand is that it is essentially a table, with some rows representing more than one possible scenario.

In browsing this afternoon, it seems like I have seen multiple times the phrase, "trying to understand the code" . Unfortunately, the early drafts were written at a time when I was just learning C++, so I guess I'm not surprised that it seems like cuneiform in places.

This is very interesting reading, and it sounds like many of you are doing some pretty cool things, including improvements to my code. If it would help, particularly if you plan to extend or modify stuff, I would be glad to try to answer any questions or clarify what the heck I was doing in some of the more "computationally dense" areas of the code.

Eric

 

[MGP]

Hi Eric,

Nice to see you around. You're program was/is very helpful to a lot of people.

MGP

 

[k_c]

New split code

I think I was able to get Eric's program to compute resplits properly. It always was correct for a single split. I just left the resplit option alone so the computation remains for either a single split or up to 3 splits. It wouldn't be hard to add the option to compute 1, 2, or 3 splits. The version I changed was 5.0.

This is what I did:

rewrote computeSplit to call new function getSplitEV

getSplitEV is a recursive function which calls new function computeEV1_0

computeEV1_0 computes EV for a single pair card that is not resplit
when splits remain, getSplitEV uses what is computed in computeEV1_0

getSplitEV returns when another resplit isn't possible

I declared my own shoe object to deal cards in order to weight the cards dealt so I could be sure of what to expect.

The only thing I changed was from when the program first calls computeSplit to when it returns from computeSplit. Assuming it's OK with Eric, if anyone is interested in viewing the new code, contact me by PM.

 

[ericfarmer]

The only thing I changed was from when the program first calls computeSplit to when it returns from computeSplit. Assuming it's OK with Eric, if anyone is interested in viewing the new code, contact me by PM.

Certainly ok with me! I would like to see the changes, and I assume others would as well. Given that several people are making modifications at this point, it seems like it would be useful to get a firmer hold on CM that everyone could access. Would there be interest in an Hg repository on bitbucket?