Software update with new split EVs

[k_c]

Version 0.70 had a bug in it ( a variable was not initialized that was accumulating probabilities) , and version 0.80 introduced a bug because i wasnt using an updated function for DAS, both bugs are fixed now in version 0.82

http://code.google.com/p/blackjack-combinatorial-analyzer/downloads/list

I am learning the hard why deep nested coding is not a good thing, debugging is tedious...

On a separate but interesting note, I wanted to bring up a point that you made me think about.
When we say optimal strategy, it means calculating the EV of every possible/allowed playing decision taking into account all the cards that are seen, and then choosing the one that gives you the highest EV. However that is only half the story for post-split optimal decision!
For post-split decisions, to get the optimal strategy you will need to look at the GLOBAL ev, in other words the ev of THE ROUND, and not just at the LOCAL ev of THE SPLIT HAND. This is especially true for the first split hand, because each playing decision on the first split hand will have an effect on what hands will possibly be dealt on the second split hand. For second split hand (assuming you dont have one card in 3rd split hand), it is sufficient to look at the LOCAL best ev because any playing decision on second split hand does not have any effect on the cards dealt on the first split hand since that hand have obviously dealt already.

While I hate to admit it, my algorithm is sub-obtimal because while my StandFunc(), HitFunc(), DoubleFunc() return their respective EVs taking into account all the cards seen only calculate a LOCAL ev for the split hand being dealt and not the GLOBAL ev. On the other hand my ResplitFunc() does return a Global ev.
Modifying my code to include GLOBAL evs is simple, but this will make the calculation super slow even on my i7 990X.
I just think it is interesting that for splits including all the cards seen is not enough to nail them optimally. Nasty splits!

In my opinion the theoretically most thorough method to get optimal split EVs would be to treat each split hand as covariable with all of the others. I actually started a program that would do this for 1 allowed split that would work similarly to my present CA, except it would store far more data, to see how far I could get. My present CA computes hands in an order such that hands that are computed later can link to what has already been computed. Since there are 10 ranks there are 10 (= 11 - 1) ways a hand can be linked. There are no links for busted hands because it is known what occurs for a busted player hand. Each link leads to 10 new links and so on.

In order to do this for split hands they need to be dealt simultaneously. Busted hands need to be considered since 1 hand can bust while the other doesn't. For a single split there would be 120 (= 11^2 - 1) ways to link later data to what has previously been computed. There would be no links if both hands have busted since it is known what occurs in that case.

In my present CA there are 3 strategies if DAN is a possibility. For 2 simultaneously dealt hands there are 9 covariable strategies if DAN is a possibility.

For every split hand that is added everything above grows exponentially.

Anyway on a computer with 2 GB RAM the program could successfully store data for standing on each of 2 tens or each of 2 nines for all drawing possibilities (excepting where both hands bust) from a single deck. Any pair less than nine crashes the program.

Re: CDP versus CDP1
I guess that maybe the comparison statement would be that CDP tends to be more optimal than CDP1, but not in all cases.

 

[iCountNTrack]

In my opinion the theoretically most thorough method to get optimal split EVs would be to treat each split hand as covariable with all of the others. I actually started a program that would do this for 1 allowed split that would work similarly to my present CA, except it would store far more data, to see how far I could get. My present CA computes hands in an order such that hands that are computed later can link to what has already been computed. Since there are 10 ranks there are 10 (= 11 - 1) ways a hand can be linked. There are no links for busted hands because it is known what occurs for a busted player hand. Each link leads to 10 new links and so on.

In order to do this for split hands they need to be dealt simultaneously. Busted hands need to be considered since 1 hand can bust while the other doesn't. For a single split there would be 120 (= 11^2 - 1) ways to link later data to what has previously been computed. There would be no links if both hands have busted since it is known what occurs in that case.

In my present CA there are 3 strategies if DAN is a possibility. For 2 simultaneously dealt hands there are 9 covariable strategies if DAN is a possibility.

For every split hand that is added everything above grows exponentially.

Anyway on a computer with 2 GB RAM the program could successfully store data for standing on each of 2 tens or each of 2 nines for all drawing possibilities (excepting where both hands bust) from a single deck. Any pair less than nine crashes the program.

Re: CDP versus CDP1
I guess that maybe the comparison statement would be that CDP tends to be more optimal than CDP1, but not in all cases.

I agree with you on the part that split hands depend on each other but only partially. As i have said in my last post, playing decisions on split hand 1 will have an effect on the possible hands for split hand 2 because split hand 2 still need to be dealt. However playing decisions on split hand 2 will not have any effect on split hand 1 because that hand got dealt (we stood or busted).

If you want I can try running your code on my computer with 24 GB of RAM, however to be able to use that much RAM you will need to build solution as x64 instead of win32 (right click on solution --> properties --> configuration manager --> platerform --> add x64)

I have made a few changes to my code now it is about 2 times faster with version 0.90
http://code.google.com/p/blackjack-combinatorial-analyzer/downloads/list

 

[k_c]

I agree with you on the part that split hands depend on each other but only partially. As i have said in my last post, playing decisions on split hand 1 will have an effect on the possible hands for split hand 2 because split hand 2 still need to be dealt. However playing decisions on split hand 2 will not have any effect on split hand 1 because that hand got dealt (we stood or busted).

It's mind boggling to think about and I have no desire to try and figure it out exactly but it's conceivable that the optimal strategy decision of any card combination in the first hand is dependent upon the net sum of optimizing the second hand. After all it's combinatorial analysis which considers everything that can happen. That's what I mean when when I say I think the hands are covariable.

It's simpler and more practical to first play hand 1 according what is presently known followed by playing hand 2 according to what is presently known and just don't worry about any possible covariability.

It could turn out that this is just a distinction without a difference. I really don't know.

If you want I can try running your code on my computer with 24 GB of RAM, however to be able to use that much RAM you will need to build solution as x64 instead of win32 (right click on solution --> properties --> configuration manager --> platerform --> add x64)

This code is unfinished and could easily have bugs. I was just looking at what may be possible but I'm not interested in developing it any further.