Eric Farmer code: wrong split EV estimates ?

MangoJ · Jun 19, 2011

London Colin said:

Maybe I did something wrong with your code, could not get your NEW_SPLIT code working (get some unrealistic output). Maybe I missed some fragments (or messed up some other parts).

But never mind, I wrote my own exact split routine, which gives a result of 0.26791 , which is in well within the simulation result 0.27085 +/- 0.00321 (just 1 SD apart). Sadly, calculation needs almost a minute...

MGP · Jun 19, 2011

Just curious what rules your using? Your sim and values aren't matching any rules I see so I'm wondering which "exact" values your calculating? If you don't have BJA3 and you're interested in these calcs I'd get it since Cacarulo provided nice reference tables.

As a side note, a straight recursive method like London's will often give exact values for deck/spl combos where you can run out of cards. We had a discussion about this on BJMath before it disappeared. For example, SPL3 one deck, SPL7 2D, etc. The other values won't be exact. To use recursion you have to make certain adjustments. Cacarulo has a method and k_c also figured one out. I use a different method.

MangoJ · Jun 19, 2011

Rules are for SD S17 DAS D9-11, no resplit.

MGP · Jun 19, 2011

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.

MangoJ · Jun 19, 2011

MGP said:

Thats true, but this only applies for fixed strategy (you play the second hand ignoring the drawn cards from the first hand). Counting, or perfect play (i.e. with composition over both hands) results should be higher.

Thanks for the table. I guess these are for Double any, as 28.1% seems rather high ?
I found a programm of John A. Nairn who claims exact splittings with split-hand recursive algorithms. Although written only for D10-11, I will need further tests.

nightspirit · Jun 19, 2011

MGP said:

Your excellent stuff is still around:
http://www.bjmath.com/bin-cgi/bjcomputer.pl?noframes;read=1262 (Archive copy) via Google

London Colin · Jun 19, 2011

MangoJ said:

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

MangoJ said:

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

But presumably your exact split algorithm is allowing for the cards drawn to the first hand(s), as you discussed earlier? (Which could explain why the answer is slightly higher.)

London Colin · Jun 19, 2011

MGP said:

I have to admit that I set about working on Eric's code without fully understanding all the intricacies of the algorithms he employed, or the code with which he implemented it. I would treat sections of code as black boxes wherever possible, just making use of the interfaces they export.

However, I did gradually get my head around how it all works, though I find the understanding to be a bit elusive. I have to re-learn stuff every time I revisit the code.

From what I can see the splitting code does allow for the possibility of running out of cards and thus not being able to split to the theoretical number of permissible hands. There is in any case a limit of 3 splits (i.e. 4 hands), so this only comes into play when evaluating subsets, not the full shoe.

I can't guarantee there aren't bugs in this area, but if it works as intended I think it should always give answers that agree with yours. (If I've understood correctly the issue you are raising.)

[Actually, I did have to apply a few bug fixes, not directly related to splitting, but to dealing with small subsets rather than full decks. There may be a few such bugs still lurking.]

MangoJ · Jun 19, 2011

London Colin said:

The 26.559% is the EV for a fixed strategy, i.e. a compositional play 2 vs. 6 (with an additional 2 removed from the deck). That EV is accurate - but only applies for the first of the split hand. (see simulation result 26.53% +/- 0.37% in post #1). If the second hand is played according to the same fixed strategy, then of course the second hand has the same EV.

This fixed strategy approach is quite convenient to calculate and a good and fast approximation, it is not exact as claimed by MGP (in terms of "optimal").
The reason is, that cards drawn for the first hand are not just "burned" cards with respect to the second hand. Burned cards are unknown to the player, clearly this is not the case for a split.
With knowledge of the card drawn on the first hand, playing efficiency can be improved on the second hand, and thus leads to an increase in EV for the second hand (27.60% +/- 0.37%) - which is quite substantial (at least for 22vs6).

To compute this EV increase on the second hand due to improved playing efficiency, one needs to cycle to all standing (or busting) first hands, and for each of those hands compute exact EV of the second hand played afterwards, with condition that the drawn cards on first hand are removed from the deck. This approach (which squares the afford of computation!) would indeed deserve the label "exact".
My 2-hand CA results for such an exact split is 26.79129243%. The only comparison available for the moment is my 500k run simulation (independent from this calculation) of 27.085% +/- 0.321%, which agrees reasonable well to this 26.79% (off by 1SD), compared to the approximated 26.56% result (almost off by 2SD).
Of course a higher number of runs would be better to get smaller standard error of results. A 5M run simulation should reduce SD to 0.1%, which should give a lot more clarification on this - however highly theoretical - topic.

MangoJ · Jun 19, 2011

London Colin said:

As far as I understand Eric's code, he calculates probabilities that a 3-hand split, or 4-hand split will occur analytically. Unless he didn't messed up with faculties or combinatorial coefficients (i.e. on zero arguments), such probabilities should be exact even when running out of cards (with a consequence that a 4-hand split would have a probability of zero). Hence it should also work with subsets of shoes.

London Colin · Jun 19, 2011

MangoJ said:

It's a fixed stategy, but not as you describe it. Again, I refer you back to the previous thread - [post]216927[/post]

The EV is a weighted sum of all the possibilities - two hands with one additional 2 removed, three hands with two additional 2s removed, four hands with 3 additional 2s removed.

[I'm not sure whether the code allows for the possibility that at some point further resplits might no longer be the correct strategy decision, because of the changed deck composition, but certainly it allows for other post-split hands to be played differently, and calculates the EV of the splits accordingly.]

MangoJ said:

That's where the strategy is indeed fixed. All post-split hands (for a given number of splits) are assigned the same EV, as the same strategy is assumed for each of them.

MangoJ said:

Indeed, that's what I was suggesting, you get a higher value than I (or MGP) would get because you are not employing a fixed strategy.

MangoJ · Jun 20, 2011

London Colin said:

I'm sorry, my example was for a no-resplit game, I didn't mentioned that. In such a game deeper splits aren't of concern.

But yes, as far as I understand this approximation for splits (I guess it comes from Griffin), you would need to calculate a 2vs6 with one 2 removed, 2vs6 with two 2s removed, and 2vs6 with three 2s removed, and then weighting according to the probability of getting exact 2 split hands, exactly 3 hands, or exactly 4 hands (assuming the fixed strategy says resplit).

However, when calculating the EV for exactly two (and three) split hands, one needs to be very careful, as there is a hidden condition that the card drawn to the split hand is not itself a 2 which needs to be respected. Otherwise the split is biased - this can be a bit messy but nothing impossible. I'm not sure if Eric follows this condition, as a correct implementation must also depend further on resplit rules (i.e. when there is no resplit allowed, such a constraint is not necessary). However I cannot find such a rule-dependent statement in his code - but I didn't understand his code that well.

assume_R · Jun 20, 2011

Eric Farmer

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

Now I probably made mine differently from your CA's, because I have a fixed strategy. I am assuming the player will not change his strategy (i.e. maybe hit his 12v6 even if the current deck composition says that's the best play), because I just don't see how one would use that value in real life.

In my opinion a CA should give exact results for how one would play in real life. If one specific deck composition means his strategy should change, will a player know that the deck composition is exactly that in real life?

My second split EV is .304022 and my third is .305366, all of which compute in under a second. Again, this agrees with k_c's "fixed strategy" result.

Edit: Crap I posted this in the wrong thread. Could a mod please move this to the other thread "Eric Farmers Code..."???? Thanks.

London Colin · Jun 20, 2011

MangoJ said:

Actually, you did specify no resplit for the example; I kind of forgot about that when getting into detailed discussion about algorithms.

My point was that I believe the definition of 'exact' from MGP, Cacarulo and Don Schlesinger, used to generate the tables in BJA3, is the one which Eric's (modified) code uses. (Though there may be some discrepencies which I have yet to find.)

And presumably it would not be practical to use your (more exact) approach when resplits are allowed?

MangoJ said:

It can be difficult to follow, but I believe the code is correct. (Though the section of code that does what I think you are talking about is one to which I had to apply a bug-fix. There was the potential for division by zero. I actually corresponded a little with Eric: apparently the division by zero didn't cause an issue with the compiler he was using, whereas I was getting a crash (as I would expect).

Oroginal code -

Code:

                                // If further resplitting is allowed, condition
                                // on NOT drawing an additional pair.
                                double p = shoe.getProbability(card);
                                if (splitHands < maxSplitHands) {
                                    p /= pNoPair;                                }
                                if (card != pairCard
                                        || splitHands == maxSplitHands) {
                                    valueUpCard += value*p;
                                }
                                currentHand.undeal(card);
                            }
                        }
                        valueSplit[pairCard - 1][upCard - 1] += valueUpCard
                                *pSplit[splitHands][upCard - 1]*splitHands;
                        shoe.undeal(upCard);
                    }
                }
            }
        }
    }

to which I made the change -

Code:

                                // Prevented div by zero.
                                if (numSplits < maxSplitHands-1 && pNoPair > 0.0) {
                                    p /= pNoPair;
                                }

N.B. Just noticed that as well as adding the test for pNoPair > 0.0, I also changed maxSplitHands to maxSplitHands-1. From memory, I think that's because I made a change from using the variable splitHands to numSplits (meaning a value in the range 0..3, instead of 1..4), rather than being a further bug fix.

London Colin · Jun 20, 2011

assume_R said:

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

1D S17 D9 DAS SPL1

assume_R said:

Eric Farmer would agree with you, his original split code dictated that all post-split hands be played using the same strategy as would be the case if they were the initial two cards. (Which is what a human player would do.)

However, to me, that doesn't make sense in the context of code which is calculating optimal play. It is just as unreasonable to suppose that a human player can play every non-split hand optimally (i.e. precisely composition-dependent after whatever hit cards they have taken) as it is for the post-split hands.

There is a hierarchy of strategies, only some of which are achievable by human players, but all of which could, at a stretch, be called 'basic' by virtue of depending only on your own cards and the dealer upcard.

Total Dependent : Whether pre or post-split, just look at the hand's total.

(Limited) Composition Dependent : Play some compositions differently from how you would play the corresponding total by default. Post-split, generally revert to total dependent. (This most likely means memorizing how to play various initial 2-card compositions, plus maybe some rules of thumb for certain mutli-card holdings such a 16 vs 10. And a post-split 16 vs 10 could be considered a multi-card 16 vs 10.)

So there is a range of complexity possible for the above human strategies, then we get into the inhuman.

-

Optimal Play: Play every hand according to the precise composition of the remaining deck. Post-split, we would like to take account of all cards seen, but as a practical matter, only accounting for the pair card(s) is a lot simpler (and faster).

Eric's library generates optimal strategy/EV, but can also evaluate user-defined strategies and determine their EVs. One of my goals was to add the ability to generate a range of human strategies as well, but I didn't get very far with that idea.

MGP · Jun 20, 2011

MangoJ said:

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.

London explained it very well. These are issues we also discussed ad nauseum years ago. My CA will calculate any user defined strategy, the TD strategy, the 2C strategy, the NCard strategy, and fixed CD strategy with fixed strategies. It will also estimate optimal play by taking into account various types of cards removed allowing for some strategy changes but as London pointed out and Don always loved to point out - no one plays that way.

LOL nightspirit, I forgot about that one - I think that's one of my first on the issue after I got my burn-cards working for infinite decks. After that Cacarulo and I emailed back and forth until we nailed it down. Cacarulo got them first by a hair and then I got them with a different method.

London, Eric would be the first to admit he uses an approximation. If you fixed things properly then hopefully you can match the BJA3 numbers for SPL1-3 on 6D or even SPL2 on one deck. Splits can be calculated exactly recursively as k_c and Cacarulo can attest.

London Colin said:

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.

Nice job assume_r and that's how fast it should be. You should be calculating the entire basic strategy and all 3 split ev's in less than 30s for any number of decks. T Hopper has by far the fastest ca and can do the whole thing in under a second!

Now if you want your ca to catch up to mine, then you can add hand analysis (i.e. detailed ev's for any hand), double hand analysis (ev's for each card in a double), user defined strategies, any number of generic and fixed bonus rules including suited(allowing games like Spanish 21, Superfun 21), player-dealer push variations, NCard strategies, redoubling, surrender any number, double down rescue, realtime optimal play, eor calculations, user defined decks, exporting values to Excel, busted bet splist, saving of strategies, etc.

London Colin · Jun 20, 2011

MGP said:

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.

That being said, the original only had a boolean, yes/no option for resplits, meaning you could specify SPL1 or SPL3. I did add a numeric parameter to specify the max number of splits.

I may have only tested SPL3 previously, I don't really recall. When I get the chance I'll try a few different tests. (I actually put all this stuff on hold a while ago, as other priorities took over.

)

MGP said:

I've probably been as guilty as anyone of using wrong or incosnistent terminology when talking about what's optimal, exact, etc.

I suspect I don't fully understand all the issues at present, but now I know how to access the bjmath discussions again, there is probably an ample source of information available.

assume_R · Jun 20, 2011

MGP said:

Thanks. I am able to calculate all that, using hash tables for both dealer probabilities (this is the big one), but I also save the game states for hands already calculated to speed up the brute force split results, for which all my results are recursively calculated and exactly match k_c's output.

For example, for the 2,2 vs 6 example, I go through the CA and have a 2,10 vs 6, with a certain set of cards remaining. Somewhere later down the line with resplits, I will inevitably encounter a game state of 2,10 vs 6 with those same cards remaining, and I can just plug in my already-calculated EV. This has shaved off quite a few "tree branches" for resplitting! Note that this is a completely different hash table from the dealer probabilities hash table, because it completely eliminates a whole branch instead of just making the EV calculation of that branch faster.

But I didn't make my CA for optimal play because I never will use optimal play. Right now it has total-dependent strategy, and n-card total-dependent strategy (for Spanish 21 multi-card bonuses).

I made is specifically for Sp21 so it has DDR, multi-card bonuses, composition-dependent bonuses, suit-dependent bonuses, and custom decks all implemented. Maybe one day if I want to start playing another game with those side bets or bonuses you mentioned I'll expand it for that

, or if I see a need for those detailed EV numbers.

Precomputing the dealer probabilities hash table for each combination of rules and saving it to a file would make it faster, but I'm happy with my speed right now and have truly optimized the hell out of it.

iCountNTrack · Jun 20, 2011

MGP said:

I guess you would call it brute force method, i call the method that calculates expectation and variance exactly and optimally

I feel bad for the words exact and optimum they are being slaughtered in this thread.
As you have said, optimum strategy involves a "changing" optimum post-split strategy, where any playign decision takes into account all the cards dealt which includes all the cards on every split hand as well as dealer upcard.

MGP · Jun 20, 2011

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.

assume_r: Nice! I use a table in memory but it can also load in the table from a file. I use dealer probs to allow more manipulation with the values if need be, e.g. bonuses. 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. 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. In any case, we're talking about a few seconds and whatever works is good.

ICountNTrack: Yep, I'd call that brute-force so I agree you can calculate both an optimal and exact set of values

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