Fast Implementation for Simulation of Real Shuffles

[iCountNTrack]

Simulation of real shuffles is much more difficult than just randomizing the shoe using a robust Pseudo-RNG (no LCGs!!!) for two main reasons:

a) It is computationally much more expensive to simulate "riffling", "plugging", "cutting", "stripping" because it involves inserting and deleting into an indexed sequence container (more details below)

b) It is crucial to simulate shuffling errors such as imprecise slug grabs by the dealer, cards dropped on a riffle, imprecise plugging location in the shoe, because errors can have a significant impact on player's edge (i was always disturbed with the precision of certain advanced technique sims)

The results will depend on the complexity of the shuffle, which includes the number of steps involved in the shuffle. So for instance for a 6D shoe, having 2 giant 156 card grabs riffled will be faster than making 39 deck grabs riffle and restack. For this example, the shuffle was as single pass shuffle: split 6D shoe into 2, 39 card grabs riffled, restacked, followed by cut. Speed results on AMD Ryzen 5950X (sorry Intel, our love-hate relationship has come to an end):

100,000,000 real shuffles --> 1024 seconds
100,000,000 random shuffles --> 28 seconds

[Norm]

One of the most expensive areas in CVData is during the riffle. Typically, dealers drop one card 80% of the time, two cards 17%, 3 cards 3%, and rarely 4 cards. This is the default. Although, this can get worse in a cheap casino that doesn't change decks often. But, I believe some dealers tend to riffle less precisely at the end of the riffle because the angle of the thumb against the cards becomes more severe. Optionally, you can tune this effect, but it substantially adds to CPU time.

[iCountNTrack]

One of the most expensive areas in CVData is during the riffle. Typically, dealers drop one card 80% of the time, two cards 17%, 3 cards 3%, and rarely 4 cards. This is the default. Although, this can get worse in a cheap casino that doesn't change decks often. But, I believe some dealers tend to riffle less precisely at the end of the riffle because the angle of the thumb against the cards becomes more severe. Optionally, you can tune this effect, but it substantially adds to CPU time.

Thanks Norm, I dont have that feature implemented but sounds interesting and indeed realistic. I have my checkbook next to my keyboard and notice the same thing when i riffle the checks, towards the end of the riffle more checks are dropped. How do you implement this? Do you change the distribution of cards dropped at a deep point in the grab?

[Norm]

For 1, 2, 3, 4 four cards dropped, you set percentages at the start and end of a riffle. It gradually changes the percentages during the riffle. There is also a match uneven grabs option. When set, the "dealer" will attempt to drop more cards from the larger pile throughout the riffle instead of just dropping a big leftover bunch of cards from the larger pile.

Some of this probably makes little difference to a shuffle tracker, unlike grabs. It would to an ace sequencer. In any case, you are certainly correct that human dealers are not robots and that matters.

[Cacarulo]

Simulation of real shuffles is much more difficult than just randomizing the shoe using a robust Pseudo-RNG (no LCGs!!!) for two main reasons:

a) It is computationally much more expensive to simulate "riffling", "plugging", "cutting", "stripping" because it involves inserting and deleting into an indexed sequence container (more details below)

b) It is crucial to simulate shuffling errors such as imprecise slug grabs by the dealer, cards dropped on a riffle, imprecise plugging location in the shoe, because errors can have a significant impact on player's edge (i was always disturbed with the precision of certain advanced technique sims)

The results will depend on the complexity of the shuffle, which includes the number of steps involved in the shuffle. So for instance for a 6D shoe, having 2 giant 156 card grabs riffled will be faster than making 39 deck grabs riffle and restack. For this example, the shuffle was as single pass shuffle: split 6D shoe into 2, 39 card grabs riffled, restacked, followed by cut. Speed results on AMD Ryzen 5950X (sorry Intel, our love-hate relationship has come to an end):

100,000,000 real shuffles --> 1024 seconds
100,000,000 random shuffles --> 28 seconds

I agree. Just think about riffling.
In the case of riffling we can say that there are 2 types (left and right) with their respective errors (grab errors and drop errors). In my code, I handle these errors with a function to which I pass both variables. If the drop error is set to 4, it means that between 0 and 4 cards can be dropped randomly. Same with grab errors. For instance: it is rare that a dealer would split 52 cards into 2 equal parts of 26. In this case I can set the grab error to 3. What does this mean? that the size of the grab could be between 23 and 29 cards randomly (26 +/- 3). If I set the error to zero, the grab would be exactly of 26 cards.
The left riffle means that the bottom card of the left grab is going to be the first to land on the table.
The right riffle means that the bottom card of the right grab is going to be the first to land on the table.
This distinction is very important. A consistent dealer will always use one of these two. But it could happen that he alternates between one and the other.
The same goes for plugging, cutting, and stripping.
I would say that it is impossible for a dealer to perform a shuffle routine like a robot.

Sincerely,
Cac

[Norm]

Three maps of a simple, one pass R&R.

First, a robot dealer
Second 80% one drop, 17% 2 drop, grabs +/-6
Third, a sloppy dealer

dhh1.jpg

dhh2.jpg

dhh3.jpg

[Cacarulo]

Very interesting! In the second case, are the grabs even or uneven?

Cac

[Norm]

Uneven. +/-6.

[Karelis24]

È da un po' che ci provo, ma ho anche una domanda: nel caso numero 2 come sarebbe?

[iCountNTrack]

I regret not taking Spanish classes seriously

[Norm]

Italian I think. But, don't know what it means even translated.

[Cacarulo]

I regret not taking Spanish classes seriously

It's Italian.

Cac

[Cacarulo]

Translated: "I've been trying for a while, but I also have a question: in case number 2 what would it be like?"