Index Generation

[johndoe]

I've developed a custom simulator that does a good job predicting freq, EV, and variance for blackjack and related games. I wrote my own software primarily to fully understand the game, as well as experiment with some more unusual games/strategies that aren't included in commercial sims. Plus, the programming was far easier than I expected. And fun.

The next step is index generation. The software is simply a brute-force playing simulator. To brute-force index generation, it would be fairly simple to keep track of each hand composition, and the EV of each decision as a function of TC. Where the curves cross, there's the index.

The first obvious problem is that many hands are rare enough that unless I let the sim run for a long time, it's likely I won't have enough data to keep the error reasonably low. However, if these hands are rare, the index probably isn't that important anyhow. Plus, since I can run a billion hands in a few minutes, running a few trillion-hand simulations is really not that big of a deal.

My primary interest is shoe games, so using pure combinatorics is probably not that useful. Is this correct, or are there shortcuts that allow a reasonable estimation?

The other, simplest idea is to simply "guess" at a few indicies I care about (maybe those that come up the most), run a sim for each alternative, and compare the EV's directly. Is this reasonable? In shoe games, I suspect that the hands are independent enough to allow this to work without running a sim for every possible index combination. But the influence of each index might be so small as to be lost in the noise. (But if this is the case, why should I care about the index at all?)

I've read a few articles about index generation, but is there a "definitive" source that outlines the particulars of tried and true index generation methods that I should read before I dive in?


(Edit: Clean methods for EOR calculation would also be helpful!)

[sagefr0g]

Originally Posted by johndoe

I've developed a custom simulator that does a good job predicting freq, EV, and variance for blackjack and related games. I wrote my own software primarily to fully understand the game, as well as experiment with some more unusual games/strategies that aren't included in commercial sims. Plus, the programming was far easier than I expected. And fun.

The next step is index generation. The software is simply a brute-force playing simulator. To brute-force index generation, it would be fairly simple to keep track of each hand composition, and the EV of each decision as a function of TC. Where the curves cross, there's the index.

The first obvious problem is that many hands are rare enough that unless I let the sim run for a long time, it's likely I won't have enough data to keep the error reasonably low. However, if these hands are rare, the index probably isn't that important anyhow. Plus, since I can run a billion hands in a few minutes, running a few trillion-hand simulations is really not that big of a deal.

My primary interest is shoe games, so using pure combinatorics is probably not that useful. Is this correct, or are there shortcuts that allow a reasonable estimation?

The other, simplest idea is to simply "guess" at a few indicies I care about (maybe those that come up the most), run a sim for each alternative, and compare the EV's directly. Is this reasonable? In shoe games, I suspect that the hands are independent enough to allow this to work without running a sim for every possible index combination. But the influence of each index might be so small as to be lost in the noise. (But if this is the case, why should I care about the index at all?)

I've read a few articles about index generation, but is there a "definitive" source that outlines the particulars of tried and true index generation methods that I should read before I dive in?

JD, not trying to hijack your thread, just a side question.
in your sim, how did you treat your logic for dealing with aces (ie. thier dual values)?

[johndoe]

Originally Posted by sagefr0g

JD, not trying to hijack your thread, just a side question.
in your sim, how did you treat your logic for dealing with aces (ie. thier dual values)?

Just like you would when playing. Soft hands are flagged and handled uniquely, per the strategy in use. (i.e. "if the hand is soft, go look at the soft strategy for the total, instead of the hard total strategy"). When you stand, it totals the hand using whatever value doesn't bust.

[FLASH1296]

Is your custom software capable of deriving "Risk Averse" indices?

Is there ANY chance of your software being ported to the Macintosh ?

Macs run O.S. 10.6 which is nothing more than an ultra functional
user-friendly G.U.I. over a UNIX Kernel, known as "B.S.D."
[Berkely System Distribution]

[johndoe]

Originally Posted by FLASH1296

Is your custom software capable of deriving "Risk Averse" indices?

Is there ANY chance of your software being ported to the Macintosh ?

Macs run O.S. 10.6 which is nothing more than an ultra functional
user-friendly G.U.I. over a UNIX Kernel, known as "B.S.D."
[Berkely System Distribution]

Well, right now it doesn't calculate *any* indicies (it just uses them). But I suppose it could given a little extra work; I'd imagine it would mostly be using variance as a value metric, instead of EV. First things first though.

As for a Mac version, probably not, as I don't have a Mac nor do I have any experience developing software for them. But I see no reason an emulator can't be used. It might slow things down a tiny bit, but in these days of modern processors it won't matter much.

[FLASH1296]

Actually Windows is BOTH faster and more stable running on a (modern) Mac than running on a WinTel Box.

This is always shocking to PeeCee users, except for the publishers of P.C. Magazine that is.

[dumbWinner]

Originally Posted by johndoe

I've developed a custom simulator that does a good job predicting freq, EV, and variance for blackjack and related games. I wrote my own software primarily to fully understand the game, as well as experiment with some more unusual games/strategies that aren't included in commercial sims. Plus, the programming was far easier than I expected. And fun.

The next step is index generation. The software is simply a brute-force playing simulator. To brute-force index generation, it would be fairly simple to keep track of each hand composition, and the EV of each decision as a function of TC. Where the curves cross, there's the index.

The first obvious problem is that many hands are rare enough that unless I let the sim run for a long time, it's likely I won't have enough data to keep the error reasonably low. However, if these hands are rare, the index probably isn't that important anyhow. Plus, since I can run a billion hands in a few minutes, running a few trillion-hand simulations is really not that big of a deal.

My primary interest is shoe games, so using pure combinatorics is probably not that useful. Is this correct, or are there shortcuts that allow a reasonable estimation?

The other, simplest idea is to simply "guess" at a few indicies I care about (maybe those that come up the most), run a sim for each alternative, and compare the EV's directly. Is this reasonable? In shoe games, I suspect that the hands are independent enough to allow this to work without running a sim for every possible index combination. But the influence of each index might be so small as to be lost in the noise. (But if this is the case, why should I care about the index at all?)

I've read a few articles about index generation, but is there a "definitive" source that outlines the particulars of tried and true index generation methods that I should read before I dive in?


(Edit: Clean methods for EOR calculation would also be helpful!)

I am trying this for some days. The method i am using is pick the random combinations probability of occurance for each hand. Depending on how many indices the user is willing to learn ( or how many indices the user thinks is enough) sort them and calculate the index for that hand.