Myoo: Recursion problems in strategy generation

[Myoo]

I'm surveying whatever literature I can find on optimal total-dependent basic strategy generation before I start to build a generator of my own. I can't find anything that spells out the state-of-the-art methodology, so I'm trying to absorb and infer as best as I can from what I can find here, in the discussion of Appendix A of BJA3, and elsewhere.

One issue I haven't seen addressed is that truly accurate strategy generation has to be recursive(as best as I can tell). For example, it's fairly obvious that in order to determine whether to double 9 v 2, we must first know how we would play out the rest of the hand. In other words, we have to know the parts of basic strategy "above" the total of 9. This is presumably why most strategy generators begin with player totals of Hard 17, then proceed "downwards" through all hard hands, then soft hands, then splits: One follows the other.

What is less obvious is that in order to determine the correct way to play out the rest of the hand, we must first know how we will play 9 v 2!!! Total-dependent basic strategy requires us to construct a probability distribution indicating the frequency of each possible composition for a given hand total. But the contents of that probability distribution depend on how one plays the hands "below" it (ie, on typical strategy charts).

This suggests the need for an iterative function in order to determine proper BS. Has anyone calculated BS that way? Perhaps there are no real examples in which the effect would result in changes to basic strategy. But it would theoretically be the right way to compute optimal strategy, I think.

The reason I started looking at this is because I want to build a strat generator, the right way. So ultimately, my question is: If not through such an iterative function, how else would one determine an accurate probability distribution for a given total?

[Norm Wattenberger]

CVData has an iterative option, but only when generating RA indexes. I call them iRA indexes. RA indexes are far more likely to be improved by iteration. Still, I haven't seen any improvement. Which would indicate no improvement for EV-maximizing indexes.


Serious Blackjack Software

[Norm Wattenberger]

On another site, you received the following response "There may be two or three TD strat generators out there, but the normal approach is to do comp dependent strategy, then reduce to TD."

This is a very strange comment. CVData and SBA are both TD and CD generators. I believe Cac's is similar. We don't create a CD strategy and then "reduce" to create a TD strategy. We create one or the other. I don't see the point of that at all.

[Don Schlesinger]

I've written to Cacarulo, who has promised to try to answer when he gets a moment.

Don

[OldCootFromVA]

I wrote such a program a few years back, but found I had to take a few "shortcuts" especially in the area of splitting pairs, because the number of permutations became so large it would've taken the poor computer months to wade through them all.

The net result: no difference from what you'll find published.

[Myoo]

Would it work to use the iRA generator, use a count where the tags for all denominations are set to 0, and the bet is always 1 unit?

Although, in light of your findings, I'm not too excited about the outcome.

[Myoo]

Thanks Don

[Norm Wattenberger]

If you specify the same file for input and output, after the generation just click Start Sim again for a second pass, and again for a third. However, I've never seen a difference even with RA indexes. RA indexes are far more sensitive to two passes because they both change and are affected by variance.

> Would it work to use the iRA generator, use a count
> where the tags for all denominations are set to 0, and
> the bet is always 1 unit?

> Although, in light of your findings, I'm not too
> excited about the outcome.

[Myoo]

Specifically, if the first pass indicates to double on 9 v 2, will the second pass "filter out" the combination (6,3,3) v 2 as one of the possible 12 v 2 totals?

More generally, does CVIndex use some variation of the "Cascading Process" described in TOBJ ch 11?

[Norm Wattenberger]

> Specifically, if the first pass indicates to double on
> 9 v 2, will the second pass "filter out" the
> combination (6,3,3) v 2 as one of the possible 12 v 2
> totals?

Yes. In fact the first pass does this if you seed it with the standard Basic Strategy. Generators are generally seeded with a starting strategy. There is no reason not to seed the first pass with the standard BS.

> More generally, does CVIndex use some variation of the
> "Cascading Process" described in TOBJ ch 11?

Yes and no. Most sims are built with BS to start and add complexity step by step. The philosophy of CVData is to assume complex strategies. For example, all CVData sims assume extreme complex cover strategies. If the sim doesn't have any cover, the code path is exactly the same. This is how table driven code works. It is a little bit slower for easy sims, but much faster and more flexible for complex sims. Since people have been doing simple sims for decades, I designed CVD for complex sims. This also allows far greater flexibility in adding new features. Build from the top down, not the bottom up. So, I always assume a counting system. With a BS sim, the counts happen to be all zero.
Index generation in CVData is completely separate code. In fact, each of the tables (Hard HS, Soft HS, Hard DD, Soft DD, Split and Surr) are separate sections of code with NO code shared with the other simulators and little shared with each other, except for the RNG. Some of these routines use a combination of CA and sim. Some use a two-level sim process. Generating Hard H/S tables is the most complex.
Yes I use a cascading sequence as described in Griffin for Hard H/S. But not with CA. This is because with counting I must take into account depth and the inclusion of depth using CA makes index generation impossible with current technology without representative subsets. I believe representative subsets are a myth and won?t touch them. (Well, I did try this a dozen years ago. And didn?t like the results.)

I?m not sure that was very clear. Strategy generation is much more difficult than simulation and really unrelated. One of the problems with simulating a brand new game is that you have to generate the optimal strategy first. I?ve been through this exercise many times with games unrelated to Blackjack or any existing game, and the strategy part is always the trickiest.

[Myoo]

> We don't create a CD strategy and then
> "reduce" to create a TD strategy. We create
> one or the other.

After putting some more thought into it, I don't see how one could accurately distill optimal T-D strategy from C-D strategy, so I can see why you'd say that. On the other hand, I don't have any better ideas. Maybe CVIndex does produce truly optimal T-D strategy (By the way, would you claim that it does?), but the approach sounds a bit beyond me. Too much complexity for me to handle at this stage.

I'm increasingly curious about Cacarulo's algorithm. It sounds simpler and perhaps manageable even for this little AP.

[MGP]

You start with the CD plays then group them together. Then you play it out and compare. Make sure you eliminate hands that were doubled/surrendered/split. Then play it out again and get the strategy. You can do that several times but I can't imagine a situation where you need more than 2 passes so that's what I do.

In order for it to be truly optimal you need to include post-split hands weighted in according to their frequency, but the programming of that is insanely complicated so I don't include those.

Sincerely,
MGP

[T. Hopper]

> This is because with
> counting I must take into account depth and the
> inclusion of depth using CA makes index generation
> impossible with current technology without
> representative subsets. I believe representative
> subsets are a myth and won’t touch them. (Well, I did
> try this a dozen years ago. And didn’t like the
> results.)

I'm working on a hybrid approach that uses simulation to generate an average deck composition for each count. I have that working, the next step will be to use EORs to estimate the standard error. After that I will do what you think is impossible with current technology and compare the results. ;-)