Sonny: Calculating TC to decimal points

[Norm Wattenberger]

For there to exist some "point," you would need to calculate a different point for every penetration by the card. And that, for every composition-dependant hand. Otherwise, you are just as guilty of creating "zones" as the "freaks."

> A TC is only an interval if you define it as
> such.
> But every interval has a mean and this is
> again a point.An index by its nature must be
> a point, because it marks the separation
> between two different strategies.
> Ever since Dr. E. Thorp, TC has been defined
> by RC divided by remaining decks and the
> result of this division is a point
> reflecting the prevailing card distribution.
> Creating TC-zones is just an invention of
> the simulation freaks.

> Francis Salmon

[Don Schlesinger]

Despite your somewhat sarcastic and, of course, untrue, remark above, that I somehow "back away" when the going gets tricky, I'm not backing away at all here. I just have a few other things to do at the moment.

As both Flyboy and Norm (and I) have pointed out, you are simply wrong in your understanding of this concept, and neither the fact that you've been doing it your way for a long time nor the fact that you believe firmly in the correctness of what you're doing changes the fact that, quite simply, you're wrong in your beliefs.

Go ahead and write back with something else unpleasant or sarcastic to defend your point; Norm and I simply have a responsibility to the readers of this site to point out when a post, purporting to offer facts, is in error. In the final analysis, what you personally believe is less important to me.

Don

[Phinitum]

Norm, maybe as a public service you could do sims and publish the results? Maybe a comparison of HiLo and HiLo x 5 (count +5, -5 per card). I get the impression you have things automated to where this would cost time on a computer but not much of your time to generate indexes and do the sims.

Hopefully there wouldn't be too much haggling required over what would be a valid set of rules and conditions.

You know you are right, but it would be good to convince as many people as possible on where their efforts pay off.

[Norm Wattenberger]

The time required to calculate indexes to that degree via simulation is rather enormous. When the precision increases to that level, the non-linearity becomes evident. The curve tends to bounce up and down for some indexes. Doesn't really interest me enough.

[bfbagain]

simulation. I first started by generating another set of RA playing indices, all values, for SD, DD, 4D, 6D, & 8D with a quick 500M rounds sim following. Time: A little over 7 hours. This was done on an AMD 2600 CPU.

I then ran a CVCX sim with only 1B rounds, but for all games. Time:24 hours

The point being, that to do something like this with justice, is a far bigger task, tying up a lot of computing power than many people think it is.

As an aside, I'm attempting to setup and run some custom simulations just to see if my hypothesis regarding certain plays is even in the ballpark. To even prepare the stage for what I'm trying to do will take days.

I'm not expecting to finish anytime soon. So to ask Norm to perform a "public service" to run these sims is asking a lot.

cheers
bfb

[Titan5]

How do people find an integer index number for certain play in the first place? Isn't it true that they have to first get a decimal number or a group of numbers averaged to a decimal number? The integer index number then can be obtained from using rounding, truncating or flooring the decimal number(s). If this is the case the data may have been available somewhere.
One suggestion. The infinite deck approach for one or two decks is inherently less accurate. Then the resulting decimal index numbers are useless. Only if you use 6 or 8 decks you can get relatively reliable numbers.

[Norm Wattenberger]

> How do people find an integer index number
> for certain play in the first place? Isn't
> it true that they have to first get a
> decimal number or a group of numbers
> averaged to a decimal number? The integer
> index number then can be obtained from using
> rounding, truncating or flooring the decimal
> number(s). If this is the case the data may
> have been available somewhere.

No, an average of the decimal numbers would not provide an accurate index. The TC must be calculated in the exact manner as the player will calculate it. (This is at the heart of simulation.) Billions of plays are simulated at all relevant penetrations and the results tracked. A weighted average is calculated. But, and this is important, the truncation/flooring/rounding must occur on each play before the weighted average is calculated. Therefore, there is no "point" calculated. No "point" exists. This would be the end of index determination if TC advantages were linear. But, they aren't. Therefore additional analysis must take place in the case that there exists more than one index to determine the best.

[Titan5]

Is simulation the only way to find out index numbers? Never say Never, Always or the Only way. I do agree there are situations the index numbers are of little use. Maybe there exists more than one index number for certain plays. Case in point, for 7,7 vs dealer 8 I remember reading your post a while back showing the relative flat curve for different TCs. That means the index number cannot provide useful information for us to act on. TC=0, TC=2 or TC=3; all have significant percentage of play deviation from the perfect play if one uses the index number to make play determination. (Perfect play - the one using remaining deck card composition.)

[Francis Salmon]

> No, an average of the decimal numbers would
> not provide an accurate index.

And an average of truncated numbers would?May believe who wants!

The TC must
> be calculated in the exact manner as the
> player will calculate it.

What do you know about a player's method to calculate TC.If a TC correctly calculated should be 2.8, he will probably round it up to 3 and you consider this as 2.You're rewarding imprecision.
I told you right from the start that I calculated both TC and Index to the tenth and this has to be more precise. It's a mathematical law.

(This is at the
> heart of simulation.) Billions of plays are
> simulated at all relevant penetrations and
> the results tracked. A weighted average is
> calculated. But, and this is important, the
> truncation/flooring/rounding must occur on
> each play before the weighted average is
> calculated. Therefore, there is no
> "point" calculated. No
> "point" exists.

And what is that weighed average? Isn't that a point? Ok, you truncate it again, so you lose even the benefit of that weighing!

This would be the
> end of index determination if TC advantages
> were linear. But, they aren't.

Not linear?Are you kidding. When I run my CA-program with a loop over all TCs from -10 to +10 with steps of 0.1, I can see with my own eyes that the results are very close to linear to say the least. Every child knows that 1 TC corresponds to a shift in advantage of roughly 0.5%.It's the basis of card counting.

Francis Salmon

[Francis Salmon]

In other words, you're saying: If you have an imprecision, you just have to add another one or even better several of those and than you'll get an accurate result.
Everybody with some common sense left knows that this cannot be true.

Francis Salmon

[Francis Salmon]

Saying and repeating "You're wrong" and "You don't understand" is not an argument but it seems to be the only one you have.

Francis Salmon

[Norm Wattenberger]

> No, an average of the decimal numbers would
> not provide an accurate index.

And an average of truncated numbers would?May believe who wants!

More accurate yes. If that's the way the player counts. And ALL players trucate, round or floor including you. One decimal is no more magical than zero.

> The TC must
> be calculated in the exact manner as the
> player will calculate it.

What do you know about a player's method to calculate TC. If a TC correctly calculated should be 2.8, he will probably round it up to 3 and you consider this as 2.You're rewarding imprecision.

I know because he tells me through the numerous options. And, no I am not rewarding imprecision. I am realistically simming human capability.

I told you right from the start that I calculated both TC and Index to the tenth and this has to be more precise. It's a mathematical law.

Realism is more accurate. Precision is not the be all and end all.

(This is at the
> heart of simulation.) Billions of plays are
> simulated at all relevant penetrations and
> the results tracked. A weighted average is
> calculated. But, and this is important, the
> truncation/flooring/rounding must occur on
> each play before the weighted average is
> calculated. Therefore, there is no
> "point" calculated. No
> "point" exists.

And what is that weighed average? Isn't that a point? Ok, you truncate it again, so you lose even the benefit of that weighing!

No, it is not at all a point. And no, you do not lose that benefit at all.

This would be the
> end of index determination if TC advantages
> were linear. But, they aren't.

Not linear?Are you kidding. When I run my CA-program with a loop over all TCs from -10 to +10 with steps of 0.1, I can see with my own eyes that the results are very close to linear to say the least. Every child knows that 1 TC corresponds to a shift in advantage of roughly 0.5%.It's the basis of card counting.

This is old thinking. You go through all this extra work for extra 'precision' and then throw it all away with a statement that 1 TC is worth .5%. Nonsense. Advantage kicks in as indexes kick in. For example, there will always be a large jump when Insurance kicks in. And advantage for defensive plays meanders all over the TC curve. Forget you ever heard that and you will be much better off.

[MGP]

I don't know the answer to all the questions posted here but I'd like to point a couple of unsolicited things out.

> What do you know about a player's method to
> calculate TC. If a TC correctly calculated
> should be 2.8, he will probably round it up
> to 3 and you consider this as 2.You're
> rewarding imprecision.
> I told you right from the start that I
> calculated both TC and Index to the tenth
> and this has to be more precise. It's a
> mathematical law.

No one said it's not more precise. What they said is that the effect is negligible. I'm not sure if they're correct or not but the way I can think of testing this is simple. Simply generate indices with your count as integers. Figure out the advantage by simulating billions as always. Multiply your count by 10 and then do the same thing but using the same betting ramp at the corresponding points and then see what the advantage is.

> Not linear?Are you kidding. When I run my
> CA-program with a loop over all TCs from -10
> to +10 with steps of 0.1, I can see with my
> own eyes that the results are very close to
> linear to say the least.

I don't see why he'd be kidding. Even you admit it's not linear since "very close to linear" and "linear" are not the same thing.

I'm still working on my full CA to get exact values (and I mean exact given an assumption that deck comps probs are based solely on removals and not effected by playing strategies - so they should be closer than any sim), but my CA does do insurance calcs exactly in this manner.

Below are the exact values for insurance expectations for 2D based on the exact Hi-Lo TC's. I used 2 decks because there are fluctuations between positive and negative EV's as seen below. In 1 deck there are also up/down fluctuations but not between positive and negative. It's important to note for this discussion though that even within any given exact TC, there can be many subsets that are pooled and these subsets do not all have the same expectation. So even within a given exact TC results are not linear. Anyways - here are the values:

 

Count		EV		Prob		EV*Prob		Sum(EV*Pr) 

2		-0.008307116	0.002162763	-1.79663E-05	-1.79663E-05 

2.025974026	-0.009294555	0.00057123	-5.30933E-06	-2.32757E-05 

2.039215686	-0.008645806	0.000700784	-6.05884E-06	-2.93345E-05 

2.052631579	-0.003271964	0.0005512	-1.80351E-06	-3.1138E-05 

2.08		-0.006155593	0.00217214	-1.33708E-05	-4.45088E-05 

2.108108108	-0.005095736	0.00056175	-2.86253E-06	-4.73713E-05 

2.12244898	-0.01098195	0.00076957	-8.45138E-06	-5.58227E-05 

2.136986301	-0.006029999	0.000610501	-3.68132E-06	-5.9504E-05 

2.144329897	-0.010309278	0.00010723	-1.10547E-06	-6.06095E-05 

2.166666667	-0.006833983	0.002371784	-1.62087E-05	-7.68182E-05 

2.189473684	-0.00837717	0.000201088	-1.68454E-06	-7.85028E-05 

2.197183099	-0.000248163	0.000546889	-1.35717E-07	-7.86385E-05 

2.212765957	-0.005231034	0.000876093	-4.58287E-06	-8.32214E-05 

2.228571429	-0.00262123	0.000606111	-1.58876E-06	-8.48101E-05 

2.23655914	-0.008040041	0.00026114	-2.09957E-06	-8.69097E-05 

2.260869565	-0.002290383	0.00248055	-5.68141E-06	-9.25911E-05 

2.285714286	-0.004705672	0.000325025	-1.52946E-06	-9.41206E-05 

2.294117647	-0.002896043	0.000604702	-1.75124E-06	-9.58718E-05 

2.311111111	0.000508239	0.001015	5.15863E-07	-9.53559E-05 

2.328358209	0.001355228	0.000598426	8.11004E-07	-9.45449E-05 

2.337078652	-0.003807173	0.000359713	-1.36949E-06	-9.59144E-05 

2.363636364	0.002761779	0.002474197	6.83319E-06	-7.11149E-05 

2.390804598	0.001484744	0.000325971	4.83983E-07	-6.53216E-05 

2.4		0.00100324	0.000602508	6.0446E-07	-5.86583E-05 

2.418604651	0.000661438	0.00111267	7.35963E-07	-5.61188E-05 

2.4375		0.000387156	0.00054501	2.11004E-07	-4.2537E-05 

2.447058824	0.003715623	0.000386717	1.43689E-06	-3.82376E-05 

2.476190476	0.002616516	0.002709996	7.09075E-06	-2.26955E-05 

2.506024096	0.003274295	0.000412141	1.34947E-06	-1.76647E-05 

2.516129032	0.005470656	0.000597707	3.26985E-06	-1.32894E-05 

2.536585366	0.003442248	0.001107006	3.81059E-06	6.72995E-06 

2.557377049	0.006329472	0.000540509	3.42113E-06	1.18356E-05 

2.567901235	0.002619531	0.000423812	1.11019E-06	1.30815E-05 

2.6		0.00442608	0.002701857	1.19586E-05	2.9623E-05 

2.632911392	0.001543417	0.000422358	6.51874E-07	3.18637E-05 

2.644067797	0.010571792	0.00059039	6.24148E-06	4.02047E-05 

2.666666667	0.008050885	0.001092398	8.79477E-06	5.46809E-05 

2.680412371	-0.010309278	2.60629E-05	-2.6869E-07	5.59417E-05 

2.689655172	0.004505934	0.000596071	2.68586E-06	6.03788E-05 

2.701298701	0.013258835	0.000407963	5.40912E-06	6.5272E-05 

2.708333333	0		4.51399E-05	0		6.4461E-05 

2.736842105	0.011655827	0.002785261	3.24645E-05	9.8295E-05 

.

When the index is floored you get an index of 2. If you want the EV maximizing exact index you get 2.363636. If you take the weighted EV of all values from 2 up to but not including 2.363636 you get:

-9.59144E-05 or -0.01%,

or if you use 2.3 as the cutoff which would be the floored TC to 0.1 accuracy we get:

-9.58718E-05 or -0.01%

which represents the lost EV by flooring with a unit bet. So in the case of insurance at least with Hi-Lo in 2D, the potential EV lost is small by rounding.

It's not clear if the aggregate effect over the whole game may be bigger or smaller, but since insurance pays 2-1 which is greater than any other bet, it's probably safe to assume the effect is less for any given play. Since there are 550 different plays - if we assumed the effect was about the same for each play and that we could gain 0.01% on every play - there is a potential to gain of about 5%.

However, it's obvious that not every play has an index that appears during game play - if we assume only 22 plays actually matter - then we could potentially gain 0.2% if the bet were the same at each affected TC and more if you include the effects of the betting ramp. So it may be possible to get 0.3% when including the betting ramp.

It would be interesting to see the results of the index*10 experiment I suggested above.

Sincerely,
MGP