Javascript simulation with graphs

[Cacarulo]

Hello; Don, you have a lot of footsteps to follow in! The progressive levels of confidence that you used was a big help. I run ten threads for each player hand-upcard combination and use the mean of the results. I used each thread as a measurement and generated 99% confidence intervals for each action, then if the top two actions overlapped I redid it with more iterations. Starting at 100,000, then 1,000,000, then 10,000,000 if necessary. It takes less than an hour for one data point and typically all but a few make 99%.

The data points used integer true counts only. Generating decks ahead of time with the desired count saves a lot of time; it just takes a few minutes until the count gets to about 10, then there is an exponential-like increase, close to two hours for 14. I use the pattern of card counts, how many 0, +1, and -1 cards are before and after the deck position, then populate and shuffle them internally based on the pattern to get the decks, then shuffle the cards after the deck position to get more. 100,000 iterations looking for a count of 14 generates only about 25 deck patterns. I hope this does not introduce any sort of bias.

Then running a sim to get the hand frequencies, advantage, insurance, variance, and covariance takes another 45 minutes or so; it takes 1,000,000,000 hands to get consistent data. 11 data points took a total of about 18 hours of running time. Not as efficient as Norm, but hey, I did it. (Using floating-point math and lots of multi-dimensional arrays.)

The problem: the basic strategy comes out correct, but I do not know if the graphs for all the counts come out right. For 8,8 vs. T, the lines for split and stand have a reverse slope from the ones in the back of the Hi-Lo book. And the indices do not all match. And the variance/s.d. seems to increase faster than it should at high counts. That's what makes me think there is a bias somewhere.

Four decks, and the rules specified for the illustrious 18 in BJA3.

Attachment 5049
Attachment 5052
Attachment 5050
Attachment 5051

Hi, I agree with Don about the indices 10vT and 15vT being very low. I'll give you some indices for 4D, Hi-Lo so you can see the difference that exists:

10 vs T = +3.8
64 vs T = +4.0
73 vs T = +3.5
82 vs T = +3.7
55 vs T = +3.9

15 vs T = +4.2
T5 vs T = +4.1
96 vs T = +4.0
87 vs T = +4.1

Hope this helps.

Sincerely,
Cac

[BackCounter]

The problem was in the hole card selection. It was based on a regular deck and that threw everything off. Now based on the deck with the current count, the 8,8 vs 10 graph looks like the one in the Hi-Lo book. And the variance does not go up as fast.

88vs10.jpg

ramp3.png

Risk-averse indices from graphing CE rather than EV (note 10 vs 10):

10v10.jpg

10v10_ra.jpg

The graphs do look a little wobbly; will probably need to do more iterations at the expense of more time.

Can't get away from generating deck patterns without one sim taking 5-10 hours for the high counts. The program walks through a deck and when it gets to the appropriate count, saves the pattern: deck position and the number of -1, 0, and +1 cards on each side. Any number of decks can be created from the pattern, with the actual cards shuffled and redistributed. Using integer counts, the deck position has to be a multiple or simple fraction of 52; for high counts, there are not very many patterns. But it seems to work; the results look the same as finding a new deck for every iteration.

For those who are interested . . . .

-BC

[BackCounter]

Indices, regular and risk averse:

indices_EV.png indices_ra.png

[BackCounter]

Using a bet ramp similar to BJA3:

indices3.png

[DSchles]

Quick question: Why is your index for standing on 16 vs. T 1.6? Surely that isn't right.

Don

[BackCounter]

I can't say for sure. Floored it is 1; in the book it is 0. Most of them are within 1 of the book; there are a few exceptions. The curves could be straighter; may have to get a gaming computer to speed things up and use more iterations.

The script uses only integer counts for data points; do other sims use (floored) non-integer counts?

[Gronbog]

Floored it is 1

No. Using flooring the index for standing on 16 vs T is zero.

in the book it is 0

Yes. The book uses flooring ;-p

The script uses only integer counts for data points; do other sims use (floored) non-integer counts?

Flooring is a way to obtain integral true counts from fractional ones. Any decent sim would give you the option to using flooring, rounding or truncation, as these are methods which have been used at various times by various people. I think that most agree now that flooring is the best.

[BackCounter]

I meant that my index was 1, floored from 1.6, vs. 0 in the book.
And that my sim only used decks with actual integer counts; they had not been floored. I thought about using decks with a range of counts, all floored to the same integer, but that seemed like it would be less accurate.

[Gronbog]

And that my sim only used decks with actual integer counts; they had not been floored.

This seems like an obvious bias to me.

I thought about using decks with a range of counts, all floored to the same integer, but that seemed like it would be less accurate.

Why would you think that? This is exactly what happens during actual live play.

Going back to this comment ...

The program walks through a deck and when it gets to the appropriate count, saves the pattern: deck position and the number of -1, 0, and +1 cards on each side. Any number of decks can be created from the pattern, with the actual cards shuffled and redistributed. Using integer counts, the deck position has to be a multiple or simple fraction of 52

I see another source of bias. Namely that you also need to sample a variety of penetrations for each true count. A true count of X at penetration P1 is not the same as a true count of X at penetration P2. Furthermore, the probability of true count X is not the same at all penetrations. You need to sample them at all possible penetrations at the rate at which they would naturally occur. This (and more) is why representative decks do not generate accurate results.

[BackCounter]

I used only integer counts because the goal was discrete data points along the x axis, which are then interpolated. When the lines cross at 2.7, for example, one may then floor this count for the index. Using a range of counts in the sim would blur the data points.

Here are the deck patterns for a count of 14, 4 decks. The result of walking through 100,000 decks, from zero to < 75% penetration, boiled down to just the pattern, with duplicates removed; it took about an hour and a half. (Low counts just take a few minutes.) The first number is the deck position; then the number of cards with count -2, -1, 0, 1, and 2 in the remaining deck.

(It would be easy to just make these patterns from scratch, but I wanted them to be "real," with a real distribution. There is probably a way to do it.)

[[78,0,67,31,32,0],[104,0,52,28,24,0],[104,0,53,26,25,0],[104,0,54,24,26,0],[104,0,56,20,28,0],
[104,0,55,22,27,0],[104,0,51,30,23,0],[104,0,57,18,29,0],[104,0,50,32,22,0],[104,0,59,14,31,0],
[104,0,58,16,30,0],[104,0,49,34,21,0],[130,0,42,15,21,0],[130,0,41,17,20,0],[130,0,40,19,19,0],
[130,0,43,13,22,0],[130,0,39,21,18,0],[130,0,38,23,17,0],[130,0,37,25,16,0],[130,0,45,9,24,0],
[130,0,36,27,15,0],[130,0,44,11,23,0],[130,0,35,29,14,0],[130,0,47,5,26,0],[130,0,46,7,25,0],
[130,0,33,33,12,0]]

For a count of 4:

[[26,0,77,42,63,0],[26,0,78,40,64,0],[26,0,76,44,62,0],[26,0,75,46,61,0],[26,0,79,38,65,0],
[26,0,74,48,60,0],[39,0,70,42,57,0],[39,0,71,40,58,0],[39,0,72,38,59,0],[39,0,73,36,60,0],
[39,0,69,44,56,0],[39,0,74,34,61,0],[39,0,75,32,62,0],[39,0,68,46,55,0],[52,0,67,34,55,0],
[52,0,66,36,54,0],[52,0,65,38,53,0],[52,0,64,40,52,0],[52,0,68,32,56,0],[52,0,70,28,58,0],
[52,0,69,30,57,0],[52,0,63,42,51,0],[52,0,62,44,50,0],[52,0,71,26,59,0],[52,0,61,46,49,0],
[65,0,60,34,49,0],[65,0,62,30,51,0],[65,0,61,32,50,0],[65,0,58,38,47,0],[65,0,63,28,52,0],
[65,0,57,40,46,0],[65,0,59,36,48,0],[65,0,64,26,53,0],[65,0,55,44,44,0],[65,0,65,24,54,0],
[65,0,56,42,45,0],[65,0,66,22,55,0],[78,0,54,32,44,0],[78,0,56,28,46,0],[78,0,55,30,45,0],
[78,0,58,24,48,0],[78,0,53,34,43,0],[78,0,57,26,47,0],[78,0,52,36,42,0],[78,0,51,38,41,0],
[78,0,59,22,49,0],[78,0,60,20,50,0],[78,0,50,40,40,0],[78,0,61,18,51,0],[78,0,49,42,39,0],
[78,0,62,16,52,0],[91,0,50,26,41,0],[91,0,48,30,39,0],[91,0,49,28,40,0],[91,0,51,24,42,0],
[91,0,53,20,44,0],[91,0,47,32,38,0],[91,0,52,22,43,0],[91,0,54,18,45,0],[91,0,46,34,37,0],
[91,0,44,38,35,0],[91,0,45,36,36,0],[91,0,56,14,47,0],[91,0,55,16,46,0],[91,0,43,40,34,0],
[104,0,43,26,35,0],[104,0,45,22,37,0],[104,0,42,28,34,0],[104,0,46,20,38,0],[104,0,44,24,36,0],
[104,0,48,16,40,0],[104,0,47,18,39,0],[104,0,41,30,33,0],[104,0,40,32,32,0],[104,0,49,14,41,0],
[104,0,39,34,31,0],[104,0,50,12,42,0],[104,0,38,36,30,0],[104,0,51,10,43,0],[117,0,39,20,32,0],
[117,0,37,24,30,0],[117,0,38,22,31,0],[117,0,40,18,33,0],[117,0,41,16,34,0],[117,0,42,14,35,0],
[117,0,36,26,29,0],[117,0,35,28,28,0],[117,0,34,30,27,0],[117,0,32,34,25,0],[117,0,43,12,36,0],
[117,0,44,10,37,0],[117,0,33,32,26,0],[117,0,45,8,38,0],[130,0,31,22,25,0],[130,0,36,12,30,0],
[130,0,32,20,26,0],[130,0,33,18,27,0],[130,0,34,16,28,0],[130,0,35,14,29,0],[130,0,37,10,31,0],
[130,0,30,24,24,0],[130,0,29,26,23,0],[130,0,38,8,32,0],[130,0,27,30,21,0],[130,0,39,6,33,0],
[130,0,28,28,22,0],[130,0,26,32,20,0],[143,0,29,12,24,0],[143,0,27,16,22,0],[143,0,24,22,19,0],
[143,0,28,14,23,0],[143,0,30,10,25,0],[143,0,26,18,21,0],[143,0,31,8,26,0],[143,0,25,20,20,0],
[143,0,23,24,18,0],[143,0,32,6,27,0],[143,0,22,26,17,0],[143,0,33,4,28,0],[143,0,21,28,16,0]]

[Norm]

Agree with Grongbog. You are introducing bias. An important point in research is avoidance of assumptions.

[BackCounter]

I appreciate the feedback. What assumptions do you see here?

[Cacarulo]

I meant that my index was 1, floored from 1.6, vs. 0 in the book.
And that my sim only used decks with actual integer counts; they had not been floored. I thought about using decks with a range of counts, all floored to the same integer, but that seemed like it would be less accurate.

Again, and with the use of combinatorial analysis, it is possible to calculate indices with one decimal precision. In the case of 16vT, 4D, Hi-Lo, my indices are as follows:

16 vs T = +0.1
T6 vs T = +1.0
97 vs T = +0.0

Sincerely,
Cac