Eric Farmer code: wrong split EV estimates ?

KenSmith

Administrator
Staff member
ericfarmer said:
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?
If you can come up with any useful role for the site to play here, I'm happy to help. At a minimum, links to a repository would be appropriate I think.
 
KenSmith said:
If you can come up with any useful role for the site to play here, I'm happy to help. At a minimum, links to a repository would be appropriate I think.
Thanks, Ken! I created a public repository for the "engine" code, if you want to provide a link and/or any of the following info on how to access it. The initial revision begins with what I have been calling "version 5.2".

=====

The Mercurial command to clone the repository is:
Code:
hg clone https://bitbucket.org/possiblywrong/blackjack
Bitbucket documentation:
https://confluence.atlassian.com/display/BITBUCKET/Bitbucket+Documentation+Home

The repo is "public" in that anyone can clone it, but permission is required to write ("push") to it; see the docs above for more information.

Let me know if I can help...
 

assume_R

Well-Known Member
Eric,

I just checked out your code in mercurial. Very cool! Good idea about setting up a repository.

I see you computed the dealer probabilities non-recursively. I wonder if that would be faster, as I compute them recursively. I pm'ed you a link to my recursive function.

Edit: nevermind, you don't seem to have 10 posts yet so can't receive private messages. I'll pm you if you want after you get to 10.
 
assume_R said:
I see you computed the dealer probabilities non-recursively. I wonder if that would be faster, as I compute them recursively. I pm'ed you a link to my recursive function.

Edit: nevermind, you don't seem to have 10 posts yet so can't receive private messages. I'll pm you if you want after you get to 10.
Not sure if this makes 10; if not, my address is erfarmer, at Google mail. (At least a nod to spam protection, but only a nod, since my address is already "out there" in the various readme's for the software that I post.)
 

k_c

Well-Known Member
k_c said:
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.
After doing some checking it appears my resplit algorithm only works for non-ten pairs for a single deck. I think this probably has something to do with the fact that when a non-ten pair is split 3 times there are no remaining pair cards in a single deck. In the case of splitting tens or splitting non-tens for more than one deck, splitting 3 times does not deplete a (full) shoe of all remaining pair cards.

I tried to tap into existing code and it's just a guess, but in the cases where all pair cards are not depleted by 3 splits I don't think the existing code is doing the calculation that is expected by my algorithm.

Additionally, for 3 splits it appears to me that the existing code doesn't consider the removal of enough pair cards. For single deck non-ten pairs this isn't a problem.
 
Top