Eric Farmer code: wrong split EV estimates ?

London Colin · Jun 20, 2011

Sorry

London Colin said:

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 · Jun 20, 2011

MGP said:

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

assume_R · Jun 20, 2011

MGP said:

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.

MGP said:

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 · Jun 20, 2011

London Colin said:

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 · Jun 20, 2011

London Colin said:

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 · Jun 20, 2011

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 · Jun 20, 2011

MGP said:

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 · Jun 20, 2011

MGP said:

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 · Jun 20, 2011

MangoJ said:

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 · Jun 20, 2011

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 · Jun 20, 2011

assume_R said:

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.

iCountNTrack said:

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 · Jun 21, 2011

That looks really cool. Nice work

iCountNTrack · Jun 21, 2011

MGP said:

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

London Colin · Jun 21, 2011

Too much confusion

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

London Colin said:

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.

MGP said:

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.

MGP said:

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 · Jun 21, 2011

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 · Jun 21, 2011

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.

London Colin said:

I get
SPL1: 0.2812747215
SPL2: 0.3040215446
SPL3: 0.3053660713

London Colin said:

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

London Colin said:

I get 0.1979957072

London Colin said:

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 · Jun 21, 2011

London Colin said:

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 · Jun 22, 2011

Thanks, Assume_R and k_c.

k_c said:

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.)

k_c said:

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 -

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.)
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 · Jun 22, 2011

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 · Jun 22, 2011

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.

Eric Farmer code: wrong split EV estimates ?

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Attachments

Well-Known Member

Attachments