Eric Farmer code: wrong split EV estimates ?

assume_R · Jun 22, 2011

MGP said:

MGP,

I tried TT vs 6 in my CA. For Spl1 and Spl2 I get the exact same results as you. But when I allow splitting thrice, I get .3407864272

No total-dependent changes to the strategy happen for splitting thrice? You definitely just stand afterwards? Do I definitely have a bug with my resplitting algorithm based on this discrepency? I will trace through my program to see what happens and make sure I stand after the third resplit I suppose...

Edit: In every single other pair vs 6, I get the exact same results as you for Spl3. e.g. my 7,7 vs 6 gives .2433481963.

MGP · Jun 22, 2011

assume_R said:

You have a bug.

I timed it - 17s for the entire calc including SPL1-3. Not as fast as T Hopper's but not bad for all levels of splits and storing analysis for all kinds of things.

London Colin · Jun 22, 2011

MGP said:

Eric doesn't use TD play. His original code is meant to be CDZ-, and the modified version is meant to be what I think you call CDP ?, i.e. post-split hands played with knowledge of the removed pair card(s).

(I never got to the bottom of precisely what all the different CDXXX terms mean before the bjmath.com forum which I had been browsing disappeared. But now I know how to access that again, there may be some helpful summaries to plunder there.)

Could you clarify what the tables in BJA3 represent. Am I right in thinking they are 2C?

N.B. In the preamble to those tables in BJA3, Don S. directs us to bjmath.com for optimal EVs, which is unfortunate if the values there are wrong!

If it's of any use, the net result I am currently getting is 0.001841749.
The original (CDZ-) net result being returned is 0.00182894557.

Clearly something is wrong somewhere.

k_c · Jun 22, 2011

London Colin said:

1 allowed split is a special case. When 1 split is allowed you don't need to worry about resplitting if another split opportunity is drawn. When more splits are allowed you eventually will get to the same condition sooner or later. Below is output from an old program I wrote to split an infinite shoe for some given number of limited splits. What is displayed is EV for 10-10 v 6, H17. First column is number of splits allowed. Second column is overall EV for this number of splits. Third column is EV for hand 1. Last column is EV for hand 2. As you can see EV(hand 1) = EV(hand 2) for 1 allowed split. After that EV(hand 1) doesn't equal EV(hand 2) but for a large number of splits they approach the same value.

The point is that except for one allowed split the overall EV is not just a multiple of some number of hands.

Code:

Maximum number of allowed splits:  100

Splits  EV(Overall)     EV(Hand 1)      EV(Hand 2)
1       0.5649616955    0.2824808478    0.2824808478
2       0.5059738033    0.2476243660    0.2583494373
3       0.4701177957    0.2294742453    0.2406435503
4       0.4465805431    0.2184416276    0.2281389155
5       0.4303908084    0.2111993960    0.2191914124
6       0.4188965289    0.2062179392    0.2126785897
7       0.4105457832    0.2026812378    0.2078645454
8       0.4043713301    0.2001117776    0.2042595525
9       0.3997421736    0.1982119459    0.2015302277
10      0.3962322141    0.1967875900    0.1994446241
11      0.3935458488    0.1957076025    0.1978382463
12      0.3914735241    0.1948810285    0.1965924955
13      0.3898640356    0.1942433902    0.1956206454
14      0.3886066626    0.1937481629    0.1948584997
15      0.3876193143    0.1933612790    0.1942580354
16      0.3868404762    0.1930574795    0.1937829967
17      0.3862236272    0.1928178370    0.1934057902
18      0.3857333022    0.1926280373    0.1931052649
19      0.3853422735    0.1924771680    0.1928651055
20      0.3850295069    0.1923568515    0.1926726553
21      0.3847786618    0.1922606156    0.1925180461
22      0.3845769808    0.1921834325    0.1923935483
23      0.3844144592    0.1921213769    0.1922930824
24      0.3842832188    0.1920713702    0.1922118486
25      0.3841770328    0.1920309885    0.1921460443
26      0.3840909635    0.1919983159    0.1920926475
27      0.3840210826    0.1919718330    0.1920492495
28      0.3839642565    0.1919503312    0.1920139253
29      0.3839179787    0.1919328463    0.1919851324
30      0.3838802394    0.1919186070    0.1919616324
31      0.3838494234    0.1919069949    0.1919424286
32      0.3838242301    0.1918975130    0.1919267171
33      0.3838036100    0.1918897613    0.1919138487
34      0.3837867145    0.1918834166    0.1919032979
35      0.3837728568    0.1918782180    0.1918946388
36      0.3837614796    0.1918739541    0.1918875255
37      0.3837521302    0.1918704534    0.1918816768
38      0.3837444406    0.1918675767    0.1918768639
39      0.3837381107    0.1918652106    0.1918729001
40      0.3837328960    0.1918632630    0.1918696330
41      0.3837285968    0.1918616584    0.1918669383
42      0.3837250497    0.1918603356    0.1918647141
43      0.3837221212    0.1918592442    0.1918628770
44      0.3837197017    0.1918583431    0.1918613586
45      0.3837177016    0.1918575987    0.1918601029
46      0.3837160471    0.1918569832    0.1918590638
47      0.3837146777    0.1918564742    0.1918582035
48      0.3837135436    0.1918560528    0.1918574908
49      0.3837126040    0.1918557039    0.1918569001
50      0.3837118249    0.1918554147    0.1918564102
51      0.3837111788    0.1918551750    0.1918560038
52      0.3837106426    0.1918549762    0.1918556664
53      0.3837101974    0.1918548112    0.1918553862
54      0.3837098277    0.1918546743    0.1918551534
55      0.3837095204    0.1918545605    0.1918549599
56      0.3837092650    0.1918544660    0.1918547990
57      0.3837090526    0.1918543874    0.1918546652
58      0.3837088759    0.1918543220    0.1918545539
59      0.3837087288    0.1918542676    0.1918544611
60      0.3837086063    0.1918542224    0.1918543839
61      0.3837085043    0.1918541847    0.1918543196
62      0.3837084193    0.1918541533    0.1918542660
63      0.3837083485    0.1918541272    0.1918542213
64      0.3837082895    0.1918541054    0.1918541841
65      0.3837082402    0.1918540872    0.1918541530
66      0.3837081991    0.1918540720    0.1918541271
67      0.3837081648    0.1918540594    0.1918541054
68      0.3837081362    0.1918540489    0.1918540874
69      0.3837081123    0.1918540401    0.1918540723
70      0.3837080924    0.1918540327    0.1918540597
71      0.3837080757    0.1918540266    0.1918540491
72      0.3837080618    0.1918540214    0.1918540403
73      0.3837080501    0.1918540171    0.1918540330
74      0.3837080404    0.1918540136    0.1918540268
75      0.3837080322    0.1918540106    0.1918540217
76      0.3837080254    0.1918540081    0.1918540174
77      0.3837080197    0.1918540060    0.1918540138
78      0.3837080150    0.1918540042    0.1918540107
79      0.3837080110    0.1918540027    0.1918540082
80      0.3837080076    0.1918540015    0.1918540061
81      0.3837080048    0.1918540005    0.1918540043
82      0.3837080025    0.1918539996    0.1918540029
83      0.3837080005    0.1918539989    0.1918540016
84      0.3837079989    0.1918539983    0.1918540006
85      0.3837079975    0.1918539978    0.1918539997
86      0.3837079963    0.1918539974    0.1918539990
87      0.3837079954    0.1918539970    0.1918539984
88      0.3837079946    0.1918539967    0.1918539978
89      0.3837079939    0.1918539965    0.1918539974
90      0.3837079933    0.1918539963    0.1918539971
91      0.3837079928    0.1918539961    0.1918539968
92      0.3837079924    0.1918539959    0.1918539965
93      0.3837079921    0.1918539958    0.1918539963
94      0.3837079918    0.1918539957    0.1918539961
95      0.3837079916    0.1918539956    0.1918539960
96      0.3837079914    0.1918539955    0.1918539958
97      0.3837079912    0.1918539955    0.1918539957
98      0.3837079911    0.1918539954    0.1918539956
99      0.3837079909    0.1918539954    0.1918539956
100     0.3837079908    0.1918539954    0.1918539955

MGP · Jun 22, 2011

BJA3 uses a 2C Strategy with a few post-split exceptions I believe. I disagree with using the exceptions especially since they lower the EV from a true 2C strategy. I'm too lazy to find the details right now and to double check that it's 2C although I'm pretty sure about it.

The value in the summary is the CDZ- strategy. To reiterate - that's first figuring out the CD strategy for every hand with a full deck. Then it uses that strategy for each hand without changing it for post-split hands.

London Colin said:

London Colin · Jun 22, 2011

k_c said:

If I'm following Eric's code (and your comments) correctly, it does something which gets around this for the original CDZ- case, but does throw up an issue in my modified version.

As far as I can tell, the code calculates the probabilities of splitting 1,2, or 3 times. This would seem to assume that resplitting always takes place when another pair is drawn (if allowed), regardless of the EV of other actions. (This would always be true of a CDZ- strategy, treating the post-split pair the same as it would be treated initially.)

Those probabilities can then be applied as weights to sets of 2, 3, and 4 hands of equal EV.

So it would seem my modified version makes a CD decision on post-split hands, unless the post-split hand is itself a pair, in which case it resplits (if allowed). That's a strategy of sorts, though not really the intended one. I wonder what the proper abbreviation would be?

There would appear to be other bugs, however. I am after all seeing some results where the reported EV is too large. That can only mean a screw-up somewhere in the calculations, rather than inadvertently following a sub-optimal strategy, which should reduce the EV.

iCountNTrack · Jun 22, 2011

Optimal splits value

I am enjoying the beach in southern France. I will post optimal split results(changing post split strategy) later on today when I access my computer. I don't know how helpful would that be because it is like comaprng apples and oranges. But it seems to me that the method should be standardized before making any comparisons.

MangoJ · Jun 22, 2011

MGP, that is quite an impressive tool you wrote. When you posted the rules screenshot, I noticed the DOA setting. My value of 22vs6 (SPL1) was for D9-11, so they naturally should differ (yours must be higher).
I'm not sure why I chose D9 originally, so I will need to check with DOA against your values.

London Colin · Jun 22, 2011

MGP's terminology

Thought it might be useful to post this link here. -

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

London Colin · Jun 22, 2011

London Colin said:

Or a third possibility, which MGP did hint at in a previous post, but which I overlooked -

For splitting to > 2 hands, Eric's algorithm applies some sort of an approximation. I don't as yet understand the nature of that approximation, despite staring at the code

, but here is a statement to that effect from the horse's mouth (in communication with MGP, in fact) -

(Dead link: http://www.bjmath.com/bin-cgi/bjmath.pl?noframes;read=4580) (see end of post)

MGP · Jun 22, 2011

London Colin said:

This is the conversation I remember and why I've been so insistent it was an approximation. Wow -you're bringing back some seriously old memories here LOL.

I haven't looked at this stuff for years...

London Colin · Jun 22, 2011

Having glanced at Chapter 11 of TOBJ, I think I've figured out what the issue (or at least an issue) is with Eric's code -

Although, when calculating the EVs of the split hands, he does apply the condition that a pair card cannot be drawn when performing the split (because that would mean a resplit), he reuses the dealer probabilities that have already been calculated and which do not themselves reflect this same condition.

So, for example, if considering a hand 8,9 in the context of three split 8s (meaning that there are two other hands, 8,x where x<>8), the dealer probabilities ought to account not only for the three 8s, 9, and dealer upcard being removed from the deck, but also the two non-eights.

I don't know how easy it would be to amend this, or how much of an overhead it would add (since dealer probabilities are what take up the bulk of the processing time).

MangoJ · Jun 22, 2011

London Colin said:

Eric might be right here, one should take into account that x is a non-eight when calculating EV of 8,9 vs upcard, with additional 8,x1 and 8,x2 removed.

What would be the correct approach ? Say that there is only one other hand 8,x beneath 8,9 vs upcard. Then I would use the identity of conditionals p(A|B)*p(B) + p(A| ~B)* p(~B) = p(A).
If we take "A: Result of hand 8,9 vs upcard with additional 8,x removed) and
"B: x is non-eight", we could calculate the hand of 8,9 vs. upcard with additional 8 removed (represented by p(A) ),
then 8,9 vs. upcard with additional 8,8 removed ( this is p(A| ~B) ) to get
p(A|B) which is 8,9 vs. upcard with addition 8, non-eight removed.
p(B) and p(~B) is simply known by the deck distribution.

For multiple split hands (in you example 2) the conditional identity would be nested, but would not require new data. There would be no performance overhead of the entire calculation, as we already did calculate 8,9 vs upcard with each number of additional 8 removed.

Thanks for that hint, Colin. I didn't understand Eric's split code until now then. However I have the feeling that for no-resplit rules this approach is wrong, as x may as well be an eight (and thus ignoring x as a burn card).

I hesitated opening this thread, but it turned out to be a great resource for education!

London Colin · Jun 22, 2011

MangoJ said:

Not sure what you mean when you say Eric might be right. The point I was making was that he does not do this for the dealer probabilities. I suspect this is what makes his algorithm an approximation, rather than an exact calculation. (And probably what makes it quite fast

)

MangoJ said:

My head is spinning.

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.

E.g., [4,4,4,5] can mean a single hand totalling 21, a hand of [4,4,5]=13, resulting from a single split of a pair of 4s, or a hand of [4,5], resulting from two splits. (I think that's all, but it's a while since I looked at this in detail).

Against this single row is recorded a single set of dealer probabilities for each possible upcard.

So my assumption is that, whatever the details of the approach taken, there would have to be multiple additional calculations of dealer probabilities, corresponding to each such row, handling all the various split scenarios.

MangoJ said:

You're welcome.

Regarding the no-resplit case, that has to be tested for. This is already done as far as conditioning the player's hand EV to reflect that an 8 can't be drawn (or rather that sometimes it can). I posted the relevant code fragment earlier -
[post]238630[/post]

(Remember that this code already gives exact results for the SPL1 (i.e no-resplit) case.)

The same would have to be done as far as calculating the dealer probabilities is concerned.

iCountNTrack · Jun 23, 2011

Optimal split EV

I realized that my CA doesn't record spl2 and spl3 EVs. I tried to tinker with my code to get those values but i think the combination of sun and alcohol has made my mind slower

. Anyway the EV of the first split of 9,9 vs 6 for 1D split 3 times DAS calculated optimally is +41.53314%. This value includes the
possibilty of a second and third splits (whenever they are optimal).

However as i have mentioned earlier i am not sure how useful my figure is, because it is like comparing apples to oranges, besides i feel it is always tedious to analyze somebody's else code especially when you dont fully understand the algorithm. We need to standardize the comparison (fixed, optimal, total...)

MGP · Jun 23, 2011

BJ calcs are ALL about conditional probs. You can't do dealer checks for 10/A without them and they can be key for splits.

"E.g., [4,4,4,5] can mean a single hand totalling 21, a hand of [4,4,5]=13, resulting from a single split of a pair of 4s, or a hand of [4,5], resulting from two splits. (I think that's all, but it's a while since I looked at this in detail).

Against this single row is recorded a single set of dealer probabilities for each possible upcard.

So my assumption is that, whatever the details of the approach taken, there would have to be multiple additional calculations of dealer probabilities, corresponding to each such row, handling all the various split scenarios."

You don't need to redo the dealer probs - I described this earlier. You just need to compare the different totals. In your example you'd compare to totals of 17, 13 an 9.

"Anyway the EV of the first split of 9,9 vs 6 for 1D split 3 times DAS calculated optimally is +41.53314%."

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.

iCountNTrack · Jun 23, 2011

MGP said:

First split means the overall ev of the hand. That is because the first split will include all the subsequent group of optimal decisions(hit, stand, double, resplit(hit, stand,double, resplit(hit, stand, double) ) taken based on all the cards seen. I actually thought about it a little more and figured out why I decided not to include split2 and split 3 that is because when we have an optimal changing strategy, you cannot have ONE value for the ev of split2 and split3, that is because the ev of split2 will depend one the cards in hand 1 and the ev of split 3 will depend on the cards in hand 1 and hand 2.
There is of course also the possibility of resplitting on the first hand which most CA report in general but again that will be only reporting one of the many many possible values.

London Colin · Jun 23, 2011

MGP said:

I think we may be talking slightly at cross purposes.

The different totals are of course taken care of. The whole point of the data strutcure I am refering to is to allow for this re-use in different contexts.

I'm looking at the code, trying to discern what the intended algorithm is, in what way it performs an approximation, and how/whether it could be modified so as to be exact.

This could be one of those "If I was going there, I wouldn't start from here." situations; starting from scratch might be the better option. I don't know.
(And in truth it's not something I'm going to be working on any time soon. But it's helpful to pursue this discussion now, for future reference, while we have your attention.

)

To continue your trip down memory lane, I found the 'bringing it all together' post you mentioned - (Dead link: http://www.bjmath.com/bin-cgi/bjmath.pl?read=4937)

There's a lot in there I don't follow. But from what I've so far read both here and at bjmath, it seems that you (and k_c) take an approach in which each of n split hands is evaluated separately, meaning the later hands have fewer possible resplits available to them and also have to account for the removal of more pair cards.

Eric, on the other hand, has gone down the path of treating all n split hands as being equivalent. His code would appear to adopt the definition of the EV from repeated splitting given at the start of chapter 11 of TOBJ by Griffin. (But does not use the extrapolation method that Griffin then goes on to describe.)

So it's in that context that it seems to me redoing the dealer probabilities would be necessary, as described in Griffin's example.

Griffin said:

Also, thinking about it some more, I'm not sure that the step Eric takes to get the conditional EV of a split hand (conditioned on not drawing a further pair) makes much sense.

He just divides the EV by 'pNoPair' as a final step, but surely he ought instead to not draw the pair card in the first place, limiting which hands are considered. I appreciate that may not make much sense if you are not looking at the code, but it may be of help to Mango (and to me when I look back at this in a couple of years time.

)

MGP · Jun 23, 2011

iCountNTrack said:

I was right - the CD-PN captures almost all of it but in pretty much the same amount of time as calculating regular splits:

SPL1: 0.4132682596465

London Colin said:

As long as the shoe state is the same, the dealer probs are re-useable for any context. I do that in my code as an optimization as I've already described. It is not necessary to recalculate them for any reason.

London Colin · Jun 23, 2011

MGP said:

That's surely the point. The shoe state is not the same. In the [4,4,4,5] example, having split to {4,N 4,N 4,5}, we know it is depleted by two non-fours, compared to if we were evaluating a single hand of 21.

Eric does the same optimization as you do, reusing the dealer probs whenever possible. But because of the particular splitting algorithm he is using, he is also reusing them where it is not strictly possible.

That being said, it might well be possible to replace the splitting routine with an entiely new one, without having to vastly modify the existing infrastructure, so that the shoe state is indeed always the same whenever the dealer probs are called upon.

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

Well-Known Member