MJ: CVData Suggestions

[MJ]

Is there any possibility of adding a feature which forces a shuffle when a backcounter is observing a table and the count becomes negative? This would be a great item to put on the list. The user should be able to specify an exit point for these situations based upon penetration levels. Would you continue observing a table if the TC= -3? Doubtful.

Also, consider adding a feature that accounts for lag time (how many rounds are wasted looking for a new shoe) when a player stops observing a table or departs a shoe that he has wonged into because the count tanked. Very rarely do we immediately find a freshly shuffled shoe to start observing.
The simulator should account for this factor.

Incorporating these ideas will be a step in the right direction.

MJ

[Don Schlesinger]

I see you finally made it to chapter 13. :-)

Don

[Don Schlesinger]

I see you finally made it to chapter 13! :-)

Don

[Norm Wattenberger]

The second request exists in the latest updates. I'm looking at the first along with some other ideas. I'd like to make certain all suggestions are in before implementation as this basically changes the definition of hands/hour in the sim and I've not seen such a definition in any simulator.

> Is there any possibility of adding a feature which
> forces a shuffle when a backcounter is observing a
> table and the count becomes negative? This would be a
> great item to put on the list. The user should be able
> to specify an exit point for these situations based
> upon penetration levels. Would you continue observing
> a table if the TC= -3? Doubtful.

> Also, consider adding a feature that accounts for lag
> time (how many rounds are wasted looking for a new
> shoe) when a player stops observing a table or departs
> a shoe that he has wonged into because the count
> tanked. Very rarely do we immediately find a freshly
> shuffled shoe to start observing.
> The simulator should account for this factor.

> Incorporating these ideas will be a step in the right
> direction.

> MJ

[MJ]

> I see you finally made it to chapter 13! :-)

I did read your ODP study. Twice in fact. Good stuff.

I didn't realize that by factoring in a lag time, the counter would have to be more patient before exiting the shoe. Also interesting how the further we are into a shoe, the less patient we must be!! But as you said, take the wong out points toward the end with a grain of salt. I find it difficult to believe that a counter should walk away at a TC of +2 just because they are at the end of a shoe.

You mentioned that John Auston used BJRM to determine the optimal bets for the study. To my knowledge, BJRM can only determine optimal bets for play-all and wonging in and out. But it can't really determine bets for strategies like Mr.Perfect, Wi-Wo, or White Rabbit. Perhaps you can clarify exactly what JA did to determine the bets. I assume he did not use any trial and error process that involved looking at the sim results and then trying to tweak the bets to yield a higher SCORE. That would take forever.

MJ

[MJ]

> The second request exists in the latest updates. I'm
> looking at the first along with some other ideas. I'd
> like to make certain all suggestions are in before
> implementation as this basically changes the
> definition of hands/hour in the sim and I've not seen
> such a definition in any simulator.

In my mind, Hands/Hr are simply how many hands are "dealt" per hour at a given table. It has absolutely nothing to do with hands observed/hr. But how does implementing this suggestion change the definition?

Another suggestion would be to add a feature where the software utilizes an iterative process to determine ODP values based upon penetration level and lag time. If CVData can generate indice values, why can't it determine ODP values?

MJ

[Norm Wattenberger]

> In my mind, Hands/Hr are simply how many hands are
> "dealt" per hour at a given table. It has
> absolutely nothing to do with hands observed/hr. But
> how does implementing this suggestion change the
> definition?

In every simulator I've ever seen, HPH is the overall number of hands dealt including the delay caused by shuffling. If we wish to factor out shuffling and other factors we are changing the definition. I may need to allow the user to select a definition.

> Another suggestion would be to add a feature where the
> software utilizes an iterative process to determine
> ODP values based upon penetration level and lag time.
> If CVData can generate indice values, why can't it
> determine ODP values?

Two very different concepts. The biggest problem is the large number of variables.

[Norm Wattenberger]

> In my mind, Hands/Hr are simply how many hands are
> "dealt" per hour at a given table. It has
> absolutely nothing to do with hands observed/hr. But
> how does implementing this suggestion change the
> definition?

Yes all simulators define it as hands per hour dealt including delays like shuffling. By parsing the time we would be changing the definition. In V4 I allowed HPH to mean dealt or observed by user option. I think I need to add an option for speed excluding shuffling or any other lag time.

> Another suggestion would be to add a feature where the
> software utilizes an iterative process to determine
> ODP values based upon penetration level and lag time.
> If CVData can generate indice values, why can't it
> determine ODP values?

Two very different processes.


Serious Blackjack Software