Eric Farmer code: wrong split EV estimates ?

[London Colin]

Sorry

Not sure why that should be. There are only the two fragments I posted.

Admittedly the version I ran also inlcuded lots of my other changes, but these should not have any bearing on the split result.

(If you copied all of the code I posted, including the NEW_SPLIT macro mechanism for choosing between the old and new code, the only other issue would be to make sure you #define the macro, either at the top of the module or in the compilation command line.)

Thanks to nightspirit, pointing out that we can still get at the bjmath forum posts via Google, I've got a chance to review some of the discussions that I saw on there years ago.

I should make it clear that among them was one from Eric, supplying the alternative split code which I incorporated. It's his fix, not mine -

http://www.bjmath.com/bin-cgi/bjmath.pl?read=5295 (Archive copy)

Although I've made lots of other changes, I believe it's only the above that affects the way that splits are calculated.

Aha! All becomes clear.

Mango,

If you compare Eric's original with the code I posted in the other thread, you'll see that another of my changes has sneaked in by mistake.

Throughout the original code, there are numerous expressions which index into zero-based arrays, such as:

hitHand.valueStand[split][upCard - 1];

To tidy things up, and potentially speed things up a little too, I changed all of these so that they are indexed directly, like this:

hitHand.valueStand[split][upCard];


So you have ended up with a hybrid, accessing the wrong array members. Presumably the results were garbage.

Your best approach is probably just to take the original amendments form Eric's bjmath post.

 

[London Colin]

Londin: I have Erics 5.2 calculator which I believe is the latest version and I just ran it for 99 vs 6 6D SPL3 DOA S17 and it gives: 0.463739311292233 which as you can see is slightly off so I don't think his algorithm is exactly right.

That's what you would expect. It doesn't contain the modifications we have been discussing.

 

[assume_R]

I'm not sure how saving the EV would save time though. If you play through the player hands without any ev calcs first, then you know how many times to multiply the EV by so you would never hit a state where you have the same EV for a hand.

Hmm maybe I'm not following correctly. In the 2,2 vs 6 example, I split and then have:

***Some branch in the recursive CA***
(Split Hand 1): 2,10 vs 6. I get the EV based on the dealer probs and save it.
(Split Hand 2): 2,4 vs 6. I get the EV and save it.
(Split Hand 3): 2,4 vs 6. I get the EV and save it.

***Another recursive branch sometime later***
(Split Hand 1): 2,4,10 vs 6. I get the EV and save it.
(Split Hand 2): 2,4 vs 6.

STOP! Hold on a sec - sometime previously, I've already calculated the EV of a 2,4 vs 6 with two 2's, two 4's, a 6, and a 10 removed (in red above).

Now I don't have to go through that entire branch and calculate all the EV's.

Given this is how my code works and there are several other ways for a CA to be programmed, and maybe you programmed yours differently. But I know this saved a lot of time, especially in resplits where you actually shave off a lot.

So that's an example where you do have a repeating state.

If it's post-split, then you can re-use the probs since they would be the same and then the ev calc is a simple addition/subtraction without any dealer prob calcs.

Let's say you have a 2,2 vs 6.
On your 2,10 vs 6, you then go through all the combinations for your post-split hand.

But the chance of you getting each card on your second split hand is different because the deck composition is now one 10 short. So the probabilities are different, right?

This may just be me misinterpreting what you're saying, which is based on how you programmed yours, which is different from how I programmed mine.

 

[London Colin]

Hey, guys, I'm a bit lost on your numbers. My CA gives the first split EV of 2,2 vs 6 as 0.281275, which completely agrees with k_c's results if I set "Basic full shoe CD strategy" and "Best full shoe strat of 1st split hand" on his website http://www.bjstrat.net/cgi-bin/cdca_web.exe

What rules are you specifying? Mango's example was a bit unusual -

1D S17 D9 DAS SPL1

Answering my own question, it would seem you did not specify D9.

Your figures are very close to those posted by MGP, which are identical to those in BJA3, which are for DOA.

 

[assume_R]

Answering my own question, it would seem you did not specify D9.

Your figures are very close to those posted by MGP, which are identical to those in BJA3, which are for DOA.

Yup, that was my mistake. I just did DOA. That's good to hear! Remember, this is mine for a fixed basic strategy for 1D. i.e. always doubling 8 vs 6, always standing on 12v6 (which I presume are 2 plays which could possibly change based on the deck composition).

 

[MGP]

assume_r: I get it now, it's because you're doing it recursively. I calculate based on the shoe states so never run into the same hand with the same shoe state twice. I simply need to do the calcs with 1-4 paircards removed and then the rest of the states follow. A lot of the shoe states overlap during those calcs so that's why I save the dealer probs and use those.

For example, if you have the hand 2,2,2,2 vs 6. You can reuse the dealer probs for 2,2,2 vs 6 with 1 paircard removed, and again for 2,2 vs 6 with 2 paircards removed. You just have to account for the different player total (in this case it's moot since all add up to less than 17, but not for all cases).

 

[assume_R]

assume_r: I get it now, it's because you're doing it recursively. I calculate based on the shoe states so never run into the same hand with the same shoe state twice. I simply need to do the calcs with 1-4 paircards removed and then the rest of the states follow. A lot of the shoe states overlap during those calcs so that's why I save the dealer probs and use those.

For example, if you have the hand 2,2,2,2 vs 6. You can reuse the dealer probs for 2,2,2 vs 6 with 1 paircard removed, and again for 2,2 vs 6 with 2 paircards removed. You just have to account for the different player total (in this case it's moot since all add up to less than 17, but not for all cases).

Do you ever calculate unnecessary states your way? I'm curious about your non-recursive algorithm. Could you explain a bit further or give me a link to your code?

And yes, I save all dealer probabilities also in a hash table in memory and also check the table before recalculating them.

I didn't know there were so many other people who have created CA's! I suppose I haven't been in the blackjack business long enough to know.

Edit: As an aside, calculating resplits when suits are involved and the bonuses depend on the suits takes sooooo long. I don't even bother calculating CA-based splits for those games. Because in spanish, splitting a 7,7 vs 4 can result in a 6,7,8, unsuited, suited, or spaded, and for example, after you split 7's, the resulting play for a 7,8 vs 4 depends on the suit of those 7,8's.

 

[MangoJ]

It's funny that you're trying to redine the word "exact" and even then have no idea what you're talking about. Optimal has NOTHING to do with EXACT. These are issues Cacarulo and I and others settled 8 years ago. These are not Griffin's calculations, these are actually correct.

First of all, both Ken Smith was kind enough to brute force the "EXACT" ev's of split hands to confirm Cacarulo and my work. These are not "good and fast approximations". The numbers apply to a fixed strategy which is something that you are not using despite you first say you are and then immediately say your not.

What you are talking about involves changing the strategy, which as Don would be quick to point out if he was reading this thread, is NOT basic strategy. If you're talking about optimal play then that's something else and the calculations to do that would require brute force to get an EXACT number.

Wish I were around 8 years earlier then :laugh:
You are right, I didn't specify "exact" or "optimal". Actually I'm so ignorant that I don't notice any difference in those wordings, but english is not my mother tongue so you're probably just wasting your time explaining.

Despite of wordings, what I'm interest in (why use a CA engine anyway) is the exact calculation of optimum play. "Optimum play" is the set of decisions (however complicated they may be) that maximizes EV. Actually this is most simple to understand (EV is well defined, and on a finite-state game like blackjack maximum is always existing). I don't care if such a play is possible to form into a table that you could print on paper and memorize. That is an entire different problem.
Why use optimum play (even on subsets of shoes) for non-split hand, but refuse to use it for split hands. This doesn't make sense, why use optimum play it in the first place if one is not actually interested in optimum results, but in "usable" play (whatever that means).

 

[assume_R]

Wish I were around 8 years earlier then :laugh:
You are right, I didn't specify "exact" or "optimal". Actually I'm so ignorant that I don't notice any difference in those wordings, but english is not my mother tongue so you're probably just wasting your time explaining.

Despite of wordings, what I'm interest in (why use a CA engine anyway) is the exact calculation of optimum play. "Optimum play" is the set of decisions (however complicated they may be) that maximizes EV. Actually this is most simple to understand (EV is well defined, and on a finite-state game like blackjack maximum is always existing). I don't care if such a play is possible to form into a table that you could print on paper and memorize. That is an entire different problem.
Why use optimum play (even on subsets of shoes) for non-split hand, but refuse to use it for split hands. This doesn't make sense, why use optimum play it in the first place if one is not actually interested in optimum results, but in "usable" play (whatever that means).

Curious, but why are you interested in calculating optimal play if you won't ever be able to make some form of usable strategy to memorize from it?

 

[MGP]

MangoJ: No worries. If that's what you're interested in then I'd brute force it. I have 3 kinds of composition dependent splits that my CA can calculate. CDZ which simply uses the CD strategy from the full deck without any changing post-split. CDP which takes into account the paircards that are removed and the strategy does change. and CDPN which takes into account both paircards and generic non-paircards to change the strategy. The difference in EV is minimal though as you progress through each type. I don't apply bonuses for the latter two since they're too confusing.

I don't know anyone that uses optimal play for non-split hands let alone split ones. I use the optimal play as a starting point to calculate TD or 2C strategies. The issue is that optimal play won't change a negative EV game into a positive one without really weird rules/bonuses. If you want to do that then you need to count.

assume_R: I haven't really shared my code with anyone and am not sure I'm ready to now. There's probably enough out there though from my posts that it wouldn't be hard to figure out. I'll let you know if I change my mind.

My CA does apply the bonuses post-split and the calculation for suited bonues doesn't really change - it should be straightforward.

For SPL3 I calculated all the player evs for 4 shoe states - all with the original paircard removed and then up to 4 more. A lot of these have overlapping shoe states as described - implementing the sharing of that saves a ton of time. You could easily trim out any hands not encountered in cd-play but I don't do that.

In your case, you run into the same hand multiple times - in mine nothing is ever seen more than once. I don't know for sure which is faster if you take out all optimization, but I believe mine is since you explore every branch of every tree but mine is a straightforward run through.

 

[iCountNTrack]

Curious, but why are you interested in calculating optimal play if you won't ever be able to make some form of usable strategy to memorize from it?

These calculations are for pure theoretical purposes, like it is interesting to know what the ev for optimal playing is. I have posted something in the past that only London thought it was interesting. I will repost here, maybe it will interest more people.

The following graphs show the different evs for all the possible compositions at 3 different penetrations for a 1D game (S17) using perfect play composition dependent combinatorial analysis. I however use Running counts instead of True Counts. The graphs on the left hand side show the range of evs for a given RC, while the ones on the right show the sum of weighted EVs (p_i*ev_i).
It can be seen clearly that irrespective of the magnitude or sign of the running count, on average we are moving to a positive regime, where at 10 cards remaining in the deck we will be virtually playing with an advantage at all times.

Of course the above is totally useless for playing in real life. But for me personally I would prefer to sit down and analyze the many different aspects of the game than stepping inside a casino.

 

[MGP]

That looks really cool. Nice work

 

[iCountNTrack]

That looks really cool. Nice work

Hehe thanks, again totally useless for practical purposes, but cool nevertherless.

 

[London Colin]

Too much confusion

Sorry. It looks like my poor memory and feeble brain have caused me to spread some misinformation...

I believe the 26.5593800% figure I got should be exact, as defined by MGP/Cacarulo. (i.e. for a fixed strategy of how to play the post-split hands.)

As I said, the code gives the sames results as Cacarulo's listed in BJA3 (although I don't think I ever ran an exhaustive test, just found an exact match every time I checked any particular result).

I could have sworn I remembered getting the same results as those in BJA3, after making the amendments to the code which Eric posted. But this seems not to be the case.

Moreover, I don't think I should expect it to, since the tables in BJA3 are (I believe) for a 2-card CD strategy, whereas Eric's code considers the exact composition at every stage (with the caveat, as has been much discussed, that for splits it can only additionally consider the pair cards, not the cards drawn to other split hands).

Possibly, I was remembering comparing results with those in the tables at bjmath.com, which are also provided by Cacarulo, but are described as 'optimal' (but without a description of how they were produced).

At any rate, the few tests I have just conducted have thrown up some results that match neither of these two resources. I'm not sure if this implies a problem with Eric's algorithm, or if it is simply evaluating a strategy that does not quite correspond to either of these two.

1D S17 DAS 22 vs 6

SPL1: 0.281275
SPL2: 0.305028
SPL3: 0.305372

These are exact values using a fixed strategy for splitting. I.e. no counting involved.

By the way, for no resplitting it should be easy. Just do the calcs with the extra paircard removed for one hand and multiply by 2.

So the above is what is in BJA3, whereas I get the following -

SPL1: 0.281274722
SPL2: 0.305733114
SPL3: 0.307350977

There is no corresponding table on bjmath.com for comparison.

Londin: I have Erics 5.2 calculator which I believe is the latest version and I just ran it for 99 vs 6 6D SPL3 DOA S17 and it gives: 0.463739311292233 which as you can see is slightly off so I don't think his algorithm is exactly right.

I still get the same 0.463739311292233 value with the amended code (assumimg DAS). I suppose that makes sense, when you consider that the only real contender for a post-split strategy change would be whether or not to double/hit certain totals (e.g., 11,12) with 1..3 nines removed from the shoe.

The figure from BJA3 is 0.463967
The figure from bjmath is 0.464246

[It's odd that I get a lower figure than BJA3. I would expect mine to always be higher.]


I'll add a couple more comparisons for luck -

9,9 vs 2 6D SPL3 DOA DAS S17

BJA3: 0.197956
bjmath: 0.198076
Me: 0.198231620


4,4 vs 5 6D SPL3 DOA DAS S17

BJA3: 0.111389
bjmath: 0.111454
Me: 0.112220857 (Seems like an especially large difference!)

I've done all the above tests with my own version of Eric's code, which has some of my own modifications. So I ought really to confirm that Eric's original, with just his suggested splitting modification, gives the same results. (If anyone has actually built that code and can run a quick check, I would be grateful.)

I know I won't get around to fully investigating these discrepencies for quite some time. But I'm grateful that this thread came up to help get rid of my sense of complacency! :grin:

 

[MangoJ]

It seems that someone should write a review of split EVs (as usual in science every now and then), with different methods employed by whom, results, and a comparision against simulations (both fixed strategy and optimal strategy).

It is a funny thing, although all calculations are exact within their assumptions, the only objective method of comparision will be simulation...

 

[assume_R]

I never checked BJA3 or any other method, but I'll post what results my CA gives for comparison. Remember - mine are for a FIXED strategy with no changes to basic strategy, which is why mine is probably a bit different from yours. However, you might want to also check http://www.bjstrat.net/cgi-bin/cdca_web.exe for k_c's comparison.

So the above is what is in BJA3, whereas I get the following -

SPL1: 0.281274722
SPL2: 0.305733114
SPL3: 0.307350977

There is no corresponding table on bjmath.com for comparison.

I get
SPL1: 0.2812747215
SPL2: 0.3040215446
SPL3: 0.3053660713

I still get the same 0.463739311292233 value with the amended code (assumimg DAS).
The figure from BJA3 is 0.463967
The figure from bjmath is 0.464246

For a fixed strategy (always stand on 12v6), I get:
0.4640588273

9,9 vs 2 6D SPL3 DOA DAS S17

BJA3: 0.197956
bjmath: 0.198076
Me: 0.198231620

I get 0.1979957072

4,4 vs 5 6D SPL3 DOA DAS S17

BJA3: 0.111389
bjmath: 0.111454
Me: 0.112220857 (Seems like an especially large difference!)

I get 0.1114063638

I hope this gives you some more basis for comparison, London! If you want to see any of my code let me know and I'll PM you.

 

[k_c]

Sorry. It looks like my poor memory and feeble brain have caused me to spread some misinformation...



I could have sworn I remembered getting the same results as those in BJA3, after making the amendments to the code which Eric posted. But this seems not to be the case.

Moreover, I don't think I should expect it to, since the tables in BJA3 are (I believe) for a 2-card CD strategy, whereas Eric's code considers the exact composition at every stage (with the caveat, as has been much discussed, that for splits it can only additionally consider the pair cards, not the cards drawn to other split hands).

Possibly, I was remembering comparing results with those in the tables at bjmath.com, which are also provided by Cacarulo, but are described as 'optimal' (but without a description of how they were produced).

At any rate, the few tests I have just conducted have thrown up some results that match neither of these two resources. I'm not sure if this implies a problem with Eric's algorithm, or if it is simply evaluating a strategy that does not quite correspond to either of these two.



So the above is what is in BJA3, whereas I get the following -

SPL1: 0.281274722
SPL2: 0.305733114
SPL3: 0.307350977

There is no corresponding table on bjmath.com for comparison.



I still get the same 0.463739311292233 value with the amended code (assumimg DAS). I suppose that makes sense, when you consider that the only real contender for a post-split strategy change would be whether or not to double/hit certain totals (e.g., 11,12) with 1..3 nines removed from the shoe.

The figure from BJA3 is 0.463967
The figure from bjmath is 0.464246

[It's odd that I get a lower figure than BJA3. I would expect mine to always be higher.]


I'll add a couple more comparisons for luck -

9,9 vs 2 6D SPL3 DOA DAS S17

BJA3: 0.197956
bjmath: 0.198076
Me: 0.198231620


4,4 vs 5 6D SPL3 DOA DAS S17

BJA3: 0.111389
bjmath: 0.111454
Me: 0.112220857 (Seems like an especially large difference!)

I've done all the above tests with my own version of Eric's code, which has some of my own modifications. So I ought really to confirm that Eric's original, with just his suggested splitting modification, gives the same results. (If anyone has actually built that code and can run a quick check, I would be grateful.)

I know I won't get around to fully investigating these discrepencies for quite some time. But I'm grateful that this thread came up to help get rid of my sense of complacency! :grin:

This is what I get for 2-2 v 6, single deck, s17, DAS, double on any 2 cards. These values use doubles, whereas the program on my website uses floats. To a small number of decimal places I haven't noticed many differences in what is displayed.

Max splits = 1, Split EV = 0.28127472151625599
Max splits = 2, Split EV = 0.30402835031420133
Max splits = 3, Split EV = 0.30537208689687761

The most optimal fixed strategy I use does not consider anything beyond the way the first split hand is played. The first hand is played optimally and that strategy is duplicated on all subsequent split hands.

There may be more optimal fixed strategies but I chose to be satisfied with the above. For example the way a pair hand is played in the last hand where no splits are allowed may be different from the way it would have been played in the first hand, In the first hand when more than 1 split is allowed, a pair hand is not actually played but it is resplit, so you really don't need to consider this hand until later when more information would be known. Whenever you run out of splits it would be more optimal to play the last hand optimally instead of using the strategy obtained by playing the first hand as if it wouldn't be resplit.

I think MGP uses additional information beyond the first split hand for a more optimal fixed strategy. I chose to keep it as above to minimize the chance for error and it is also easier to maintain for the way I do splits.

As far as I know Eric's program treats all split hands as equal. This is true for 1 allowed split for a fixed strategy, but is not quite right for resplits.

 

[London Colin]

Thanks, Assume_R and k_c.

The most optimal fixed strategy I use does not consider anything beyond the way the first split hand is played. The first hand is played optimally and that strategy is duplicated on all subsequent split hands.

That sounds similar to how the unmodified version of Eric's code behaves, except that it plays every split hand in the same way as an initial hand containing the same two cards.

(For what it's worth, that version gives 0.29616760826 for 1D S17 DAS DOA SPL3, 22 vs 6.)

There may be more optimal fixed strategies but I chose to be satisfied with the above. For example the way a pair hand is played in the last hand where no splits are allowed may be different from the way it would have been played in the first hand, In the first hand when more than 1 split is allowed, a pair hand is not actually played but it is resplit, so you really don't need to consider this hand until later when more information would be known. Whenever you run out of splits it would be more optimal to play the last hand optimally instead of using the strategy obtained by playing the first hand as if it wouldn't be resplit.

I think MGP uses additional information beyond the first split hand for a more optimal fixed strategy. I chose to keep it as above to minimize the chance for error and it is also easier to maintain for the way I do splits.

As far as I know Eric's program treats all split hands as equal. This is true for 1 allowed split for a fixed strategy, but is not quite right for resplits.

Equal in what way?

My understanding from the code is that it (attempts to) calculate the EVs of split hands in the context of the number of pair cards removed for every possible numer of [re-]splits. The overall split EV is then the sum of the 1x ,2x, and 3x split EVs.


I just re-ran the 9,9 vs 2 and 4,4 vs 5, 6D SPL3 DOA DAS S17 tests, using Eric's original code. I got the same answers as I posted previously. This would seem to indicate a couple of things -

1. There are apparently no strategy differences required to maximise EV on the post-split hands. (So these aren't very good test cases for the modified code. Better to use single deck, I would think.)
   
2. If there are any bugs, they lie in the original code, not in either Eric's modified splitting algorithm or any of my (supposedly unrelated) amendements. Which is somewhat reassuring.

 

[MGP]

Let me clarify. I took those values form BJA3but had a typo with 22 vs 6 SPL2 - it should have been .304028. Sorry about that.

The following values come straight from my CA. A TD strategy is just that. The strategy is completely based on the total and does not change with any card composition pre or post split regardless of the number of cards.

Mango, just because a computer is doing the calcs does not mean everyone's values are exact. Some of these are obviously approximations to the actual value. Griffin's calcs are an example of that - you can exactly compute Griffin's approximation but it's still an approximation.

If you want I can do the same thing but print the 2C values. A 2C strategy is one in which the 2 card hands are played in a composition dependent way - with the strategy not changing post-split, and then all 3 or more card hands played in a TD way. Note that Don makes exceptions like 12 vs 3 but it actually lowers the EV if you change things post-split from a true 2C strategy.

If you are using a true TD strategy - then if your values don't match mine - then your calculations are an approximation. There's nothing more to it than that. These values have been proven by brute force and multiple people. This is not something that discussing will change. It is a fact. BJMath's values are wrong and have always been wrong. We never had them updated. If Eric's don't match these - then they're wrong. Based on his description he uses TD play I believe. If it's 2C I can get you those values as well. If it's CDZ-, i.e. composition dependent with post-split hands played the same as pre- I can get those as well.

 

[MGP]

The net results are below.

One last comment. The best hands to work on for splits are the AA vs anything and TT vs 6. Those do not require anything but standing post-split. Once you get those then you try 99 vs 6 since there is only one strategy deviation from stand on evertyhing and that's to split 92 post-split.

If you can't get those then I wouldn't bother going further.

One last thing, for all the calcs it took about 20-30s so it shouldn't take forever for exact calcs.