CVData/CVCX requests

[Norm]

Well, the most complicated part is giving this a name.

[Jack Jackson]

Generically, I think so because I can mostly follow what Jack is saying. I have a particular balanced side count in mind that I haven’t publicly stated what it is. In both our cases, we are talking about a 2nd parameter (the first parameter is the main count). One reason that I liked the idea of having (unlimited) groups of plays where the user can specify alternative tags (and an alternative index) is because this would accommodate any number of extra parameters. Suppose I wanted to add a 3rd parameter (my brain isn’t ready for it, but just suppose), that would be possible by updating which plays are grouped together and their associated tags. Just to make a silly example to illustrate the point, a 2nd parameter of a balanced side count of 2 & 3 would have different groups of plays where the associated tags will all be the same except that the tags for 2 and 3 will vary from group to group. Those varying tags take into account the tag multiplier that was chosen by the user when he/she developed the strategy. If a strategy was developed to add a 3rd parameter, let’s say a balanced side count of 4 and 5, now you would make new groups of plays taking into account that the tags used for 2, 3, 4 and 5 can vary.


Sent from my iPad using Tapatalk

Hey Ben, just so i understand the method to what your saying here and before i comment any further are you proposing that "individual" hands(or groupings) are to be modified and "attached" to specific tags/playing strategys?

For example, and lets just use a crazy example for example. Lets say you have created 3 different playing strategys. Lets call them A,B,and C.

Are you suggesting that the "user" now has the ability/option that when he defines/edits his own playing strategy, that there be an option to "attach" playing strategys A,B,or C to any selected hand? Like Strategy C for all 14s. And Strategy B for all 13s. And Strategy A for just 12v2 for example?Just curious.

If so i like this method too. But is in fact different from my method/approach albeit the same idea.

[bejammin075]

Here’s another way to put it. Currently, every play has the system tags and an index. One or any number of additional balanced side counts (parameters) can be rolled up into one extra set of tags, and one extra index. The groupings would be to help with assigning/organizing the new sets of tags, but aren’t strictly necessary if the user went through each play one by one.


Sent from my iPad using Tapatalk

[Jack Jackson]

Here’s another way to put it. Currently, every play has the system tags and an index. One or any number of additional balanced side counts (parameters) can be rolled up into one extra set of tags, and one extra index. The groupings would be to help with assigning/organizing the new sets of tags, but aren’t strictly necessary if the user went through each play one by one.


Sent from my iPad using Tapatalk

Im just gonna assume you own CVdata, so i'll try to show my proposition with snapshots.

From the Playing Menu, Norm could add the "playing side count" option here where the 'user' chooses the cards he wishes to be side counted, just like he does from the Betting Menu. Once thats established the user can then "select" "attach a side count strategy" from the (what is now) the Multi-Parameter menu. Only now it would be the "Multiplier" menu as well. From there "the user" can then select his "Mutliplier file"(that he created) to be attached to and as his "side count strategy" in "combination" with the cards he choose to be side-counted. The "Multiplier File" would use the same method the Multi-Parameter files currently use.

Note: The Multiparameter file shown below would actually be the Multiplier file.

Now of course, im not saying this is how it should done. This is obviously up to Norm and how he wishes to program it. Im just sharing my two-cents on how i think it would be easiest and most convenient for the programmer and or if this is the method of choices he prefers to use.

[bejammin075]

I get what you are proposing. And I just had some more thoughts that may helpful for how to think about implementing either of the proposals. Above I said that there would also need to be a second set of indexes for each play, but actually upon further thought, I think one set of indexes would suffice for software/simulation purposes. Partly I said what I said about 2 sets of indexes because of how I internally think about my system, with a main count and optional side count. As a human, I'm not a slave to the side count and I'll drop it, e.g. opportunity to back count 2 tables. I know that when a balanced side count is applied, the tags for a given play are altered and therefore might need a different index. Most of my plays happen to use the same index whether using only a main count, or when using the side count too, but sometimes using the side count requires a different index, especially when the tags are changed substantially with a large side tag multiplier. But what I meant to get at here with this comment is whether the balanced side count implementation is your proposal or mine, for the purposes of running a sim, we can assume the simulated user is always applying the side count, therefore the simulated user only needs one set of indexes for an "always on" side count.

The way that you proposed it would work well for one balanced side count, and is 100% equivalent to my proposal when using one balanced side count. I need to retract & revise my statement from comment #68 above. The only thing needed for one or any number of balanced side counts is for the user to have the option to use different tags for different plays, no extra set of indexes is needed because we'll assume the simulated user is always using the proper index for the tags that match the play. I'm thinking of it this way to "future proof" the concept to allow it to expand to multiple balanced side counts. For example, I've often wondered, perhaps if I went with a more simple main count, if I could design let's say a system with two or three balanced sides to see if such a high PE system could be developed to beat 6:5 single deck, or perhaps other carnival games that are offered with a small number of decks and/or odd rules that increase the opportunities for side counts, and/or taking advantage of countable side bets.

But getting back on track here, a difference between how you proposed it and how I proposed it is that the way I proposed it could accommodate any number of balanced side counts. In my proposal, the side count multiplier table(s) would not necessarily need to be captured in the software, because having the ability to use altered tags for each play could take into account the application of any number of balanced side counts. If you had, say, 3 balanced side counts, when you apply that to one particular play you would have already figured out which tag multipliers to mentally apply to each side count, which would result in having just 1 set of system tags for that play.

[Jack Jackson]

I Would Like to show an illustration here in the TWO different proposed methods when keeping a balanced sidecount, while trying to keeps things as simple as possible....I have attached 2 snapshots from two different playing strategys along with the a "multiplier" table created for the primary strategy only.

The Primary Strategy is the TOP image (2-X) 1223100-1-2
note: 7&8 are neutral.

A Side-Count of 6+2, 7+2 vs X-1

When added together it would look as follows(image#2)

(2-X) 1223320-1-3

Now Lets use 14vX for this example since it has a big impact.

As you may note the index for 14vX has an index of +22 for this(primary)strategy, which is absolutetly horrendous.

But now look at the index for 14vX when the Sidecount and Primary Strategy have been added together. image2>(1223220-1-3). It now has a very impressive index of +14 right?

Now its also important to note here that since the "multiplier table" was created for the primary strategy we must ALSO use the index from the primary strategy. And for 14vX it is +22 for the primary strategy.

Now theres TWO different methods that could be approached here.

The First Method: would be to add the TWO counts together(primary+side) and just use the +14 index for 14vX right? Since we already know that 1223220-1-3 is waaaay more efficient for 14vX than the primary count is. And correct me if im wrong but this is the method your proposing correct?

The Second Method: uses a multi-parameter approach where the Two Counts are NOT added together but rather uses a "single index" from the PRIMARY strategy based on the surplus or deficit of the 6and7's vs X's. That can therefore be adjusted to your running count.

I feel this would be more effective than adding the the two counts together and using the more efficient indexes of the two. Which i "think" and feel free to correct if im wrong is the method you were initially suggesting.

[bejammin075]

Edit: I see now your written example is comparing using a side count multiple of 1, but your bottom table (which I fixated on too much) shows a 14 v T optimal side count multiple of +9.

Original comment:

Jack, I did some analysis using your tags & specifically looking at 14 v T. How are you determining your indexes? Shown in the table upper left are your main tags and side tags. To the right are all the tag possibilities when using various side count tag multipliers. In red numbers shows how those tags are affected by changing the multiplier. With larger tag multipliers, the tags become more extreme. Below is a heatmap of the efficiency of Stiff v T, calculating the efficiency based on the tags and the EoR numbers. For 14 v T, the main tags have a playing efficiency of 45.8%. For this play you have proposed a tag multiplier of +9 because that gives the maximum efficiency of 89.2%. I was not able to get CVData to give me an index for those tags for that multiplier. Not until I reduced the multiplier to +6 was CVData able to generate an index. At the botom row are the indexes from CVData under identical conditions. For a multiplier of +1, the index actually drops from 20 to 16, but then with higher side tag multiples, the index generated keeps going higher until it can't be calculated. The way this looks to me, if you used a multiplier of +2 or +3, the mental math is going to be way easier, you've captured most of the efficiency gain, and the new index is close enough to the old index you would only need to remember one index.

Jack 14 v T.jpg

[Jack Jackson]

The indexes generated for the 2 strategy's are generated using 2 decks H17. I forgot that i had the pen set at 85% when i trying to force CVdata to spit out some of the more extreme indexes. So the indexes shown are slightly inflated..

As far as the "multiplier tables" go i was well aware that +9 was too high. Thats because the online version of excel will not let me edit the number of decks. Therefore im forced to settle for the single deck numbers. I had already figured that the multiplier for 14xX would more likely be in +6 or +7 range for double decks.

The +1 i was referring too, wasnt the multiplier but rather the count of the sidecount. So if our sidecount of 67vX was +4 and our hand is 14vX we will use the Multiplier of x6 (as you noted). So that should indicate a Stand on 14vX with 1 deck remaining and a RC of 0 in the primary count, since (4x6=+24) exceed the index of +22 for 14vX.

And yes your right i wouldnt do anything crazy like try to memorize every single Multiplier, but rather only use the ones that have the biggest impact, which i have yet to determine. And only then will i use an approximation. So keep in mind im not submitting an official version here but rather a rough estimate. Its still in its infancy at the moment. Of course im waiting for Norm to add it to CVdata

[Jack Jackson]

Hey Ben, could you tell me how i go about creating those type of files? Are you exporting this into excel after running a sim? Just point me in the right direction if you could and i'll figure it out from there. Thanks.

[bejammin075]

Are you exporting this into excel after running a sim?

There’s no sim needed for data like the table in post #72. It is entirely Excel calculations. The table in #72 was copied/edited out of a much larger table of calculations. From the things you posted it looks like you know how to calculate playing efficiency using various tags and EoR numbers.

EoR Calcs 1.jpg

EoR Calcs 2.jpg

EoR Calcs 3.jpg

EoR Calcs 4.jpg

EoR Calcs 5.jpg

[bejammin075]

Jack, I forgot to mention, in post #72, only the indexes at the bottom of the figure were from a sim. I was just simming a few indexes at a time, so in like 10 minutes I just rapid fire ran CVData index sims on Stiff versus 10 Hit/stand, and then listed those indexes underneath my excel table.

[bejammin075]

Norm, sorry if this is starting to clog up your thread.

[Norm]

No problem. It belongs here.