Is the Perfect Shuffle a Myth? Part 6 - The First Crack Appears
Part 4 put the machine into the simulation. Part 5 validated the baseline. Part 6 is where the first crack appears.
The current six-deck One2Six-style model preserved the average physical-card return time almost perfectly. But the short same-card returns collapsed. The stream did not behave like six-deck physical IID.
That is the first real signal in the project.
This is not an edge. It is not a betting system. It is not a claim that every physical machine in every casino behaves exactly like this model. But it is a genuine finding inside the six-deck One2Six-style source model:
The long-run mean physical-card return time looked almost exactly like six-deck physical IID.
The short-return distribution did not.
That is the result. The mean was not the signal. The shape was.
The question became more precise
The earlier parts of this series were about building the measuring instrument. That work was not optional. A simulator that merely runs is not evidence. A simulator that loses physical card identity, returns discards too early, uses the wrong denominator, or confuses rank/suit symbols with physical cards will still produce output, but the output will not answer the question I care about.
The question in this part is sharper:
If a continuous shuffler-style source contains six physical decks, how long should it take for the same physical card to reappear?
That is not the same as asking how often a ten appears. It is not even the same as asking how often the ten of spades appears. A six-deck game contains six physical ten-of-spades cards. If the experiment is about physical recurrence, the physical identity of the card matters.
A rank/suit card is a symbol. A physical card is an object. This experiment is about the object.
In the code, a target physical card looks like this:
one2six-deck-0:T:spades
Under the physical IID baseline, the corresponding target looks like this:
physical-iid-deck-0:T:spades
That distinction is central to the project. Without physical identity, there is no way to measure whether the same card returns too quickly, too slowly, or in a different distributional shape from a true random physical-card baseline.
The correct null was six-deck physical IID
A 52-symbol IID source is useful for testing rank and suit behaviour. It can answer questions like how often a ten-value card appears, how long until another five appears, or how often the ten of spades appears as a symbol.
It cannot answer how long until the same physical card appears again, because a 52-symbol source has no physical card memory.
For this experiment, the null model had to be six-deck physical IID:
312 labelled physical cards
each draw independently selects one of the 312
no depletion
no shoe penetration
no discard tray
no shuffler latency
This is not a casino shoe. It is not supposed to be a casino shoe. It is a clean mathematical comparator for physical-card recurrence.
For one specific physical card in a six-deck physical IID model:
p = 1 / 312
The expected draw gap is 312. I record cards_between = draw_gap - 1, so the expected number of cards between appearances is 311.
That is the geometric waiting-time model. The important point is not that the formula is exotic. It is not. The important point is that the sample space has to match the question. If the question is physical-card recurrence in a six-deck shuffler, the null model needs 312 labelled physical cards, not 52 rank/suit symbols.
All shuffler experiments in this article are six-deck experiments. I am not testing four decks, five decks, or any other deck count here.
The physical IID baseline worked
The first run was one million draws from the six-deck physical IID source. I tracked two specific target cards and also pooled recurrence across all 312 physical cards.
The expected number of appearances for any one physical card was:
1,000,000 / 312 = 3,205.13
The observed target-card counts were exactly where they should have been:
| Target | Observed appearances |
|---|---|
| Physical T spades | 3,232 |
| Physical 5 spades | 3,159 |
The pooled all-card result was the real calibration check:
| Metric | Physical IID expected | Physical IID observed |
|---|---|---|
| Mean cards between | 311.00 | 310.90 |
The tail probabilities also matched the theoretical geometric baseline almost perfectly:
| Threshold | Observed | Theoretical |
|---|---|---|
| <=50 data-preserve-html-node="true" | 0.1514 | 0.1510 |
| <=100 data-preserve-html-node="true" | 0.2771 | 0.2769 |
| <=250 data-preserve-html-node="true" | 0.5532 | 0.5533 |
| <=500 data-preserve-html-node="true" | 0.8001 | 0.7998 |
| <=1000 data-preserve-html-node="true" | 0.9596 | 0.9598 |
This was a win. Not because the IID result was surprising, but because the measurement framework recovered the known answer. That meant the recurrence code was measuring the right object in the right way.
Only after that did it make sense to test the One2Six-style source.
The One2Six-style source being tested
The source being tested here is a configurable six-deck One2Six-style physical card-source model. It is not a magic random-card generator. It is a state machine.
The path is:
dealt card
-> outside the source
-> accepted discard batch
-> feeder
-> carousel shelf
-> shelf ejection
-> back of output buffer
-> front-buffer draw
That path matters because a dealt card does not simply become equally likely on the next draw. It has to travel through the machine.
The public mechanism trail supports modelling this family of machines as physical card-handling devices rather than abstract IID generators. The ONE2SIX OTS product material describes a continuous shuffler capable of handling up to six decks and continuously shuffling four, five, or six decks. Patent material describes card handling devices with feeder paths, compartments, carousel structures, and group movement of cards through a shuffling mechanism.
The current model assumptions are:
6 decks
38 carousel slots
10-card slot capacity
output buffer target 18
refill threshold 8
minimum ejection occupancy 7
whole selected shelf ejection
LIFO shelf order
instant ingestion of accepted discards
Those are assumptions. They are not claims of exact production certainty. But that is the point of the project: make the assumptions explicit, build the model, test the output, then vary the assumptions instead of hand-waving about a black box.
The first One2Six recurrence run
The first One2Six source-level recurrence experiment used:
draws = 1,000,000
deck_count = 6
recycle_batch_size = 20
seed = 42
This was not blackjack. There were no player decisions, no betting, no strategy, and no EV calculation. The experiment simply drew cards from the source, held them outside the source, returned them in ordered batches, allowed the source to ingest them, and measured how long it took for the same physical card to appear again.
If I had only looked at the mean, the result would have looked boring:
| Source | Pooled mean cards between |
|---|---|
| Physical IID | 310.90 |
| One2Six, batch 20 | 310.95 |
That is almost identical. If the diagnostic had stopped there, I would have missed the result entirely.
The tails told the real story:
| Threshold | Physical IID theoretical | One2Six, batch 20 |
|---|---|---|
| less than 20 | 0.0652 | 0.0053 |
| less than 50 | 0.1510 | 0.0529 |
| less than 100 | 0.2769 | 0.1665 |
| less than 250 | 0.5533 | 0.5228 |
| less than 500 | 0.7998 | 0.8235 |
| less than 1000 | 0.9598 | 0.9765 |
This was the first genuinely interesting result in the project. The same physical card was dramatically less likely to reappear very quickly under the One2Six-style source model. By 500 to 1000 cards, the distribution had caught up and slightly overshot the IID benchmark.
That is the shape a stateful recycling system can create: fewer immediate returns, more medium-later returns, the same long-run physical population, and almost the same long-run mean.
The machine has memory. Not mystical memory. Mechanical memory. The card is somewhere. It is in a batch, a feeder, a shelf, a buffer, or outside the source. Its location changes what can happen next.
The sensitivity test strengthened the result
The obvious objection was that the result might just be an artifact of returning cards in batches of 20. That would still be interesting, but it would be a weaker result.
So I ran the same one-million-draw experiment across several recycle batch sizes:
1
5
20
52
100
Again, all of this was six-deck only.
The result was:
| Recycle batch size | Mean between | P less than 20 | P less than 50 | P less than 100 | P less than 250 | PP less than 500 | P less than 1000 |
|---|---|---|---|---|---|---|---|
| 1 | 310.93 | 0.0158 | 0.0697 | 0.1895 | 0.5313 | 0.8175 | 0.9730 |
| 5 | 310.94 | 0.0130 | 0.0664 | 0.1840 | 0.5288 | 0.8185 | 0.9735 |
| 20 | 310.95 | 0.0053 | 0.0529 | 0.1665 | 0.5228 | 0.8235 | 0.9765 |
| 52 | 310.94 | 0.0023 | 0.0295 | 0.1318 | 0.5057 | 0.8336 | 0.9815 |
| 100 | 310.96 | 0.0012 | 0.0171 | 0.0898 | 0.4731 | 0.8507 | 0.9884 |
The physical IID probability of a same-card return within 20 cards is about 0.0652. With a recycle batch size of 1, the One2Six-style source produced 0.0158. That is about one quarter of the IID short-return rate.
With a recycle batch size of 20, it dropped to 0.0053. With a recycle batch size of 100, it dropped to 0.0012.
The direction is obvious. Bigger recycle batches create longer delay. But the important result is that the effect does not disappear at batch size 1. Even if every dealt card is returned as quickly as possible, it still has to move through the feeder, shelf, ejection, and output buffer. That alone is enough to suppress very short physical-card returns in the current six-deck model.
This was the main win of the day. The short-return suppression was not a one-run curiosity and it was not simply “because I used batch size 20.” It survived the first sensitivity sweep.
What appears to be new here
Before writing this, I looked again at the public trail around mechanical shufflers and CSM analysis. There is serious prior work, but it is not the same as this experiment.
Diaconis, Fulman, and Holmes analysed casino shelf shuffling machines. That work is important because it shows that mechanical shufflers can be treated as real probability objects rather than folklore. It is about shelf shuffling and mixing behaviour, not this specific six-deck continuous-recycling physical-card recurrence test.
Stephen How’s CSM blackjack work is also important. He focused on buffer depth, recently fed cards, muck timing, and windowed Hi-Lo style counts. That is close in spirit because it treats a CSM as a stateful process. But it is not the same as measuring same-physical-card return-time distributions against a 312-card physical IID null and then sweeping recycle batch size.
The patent and product materials describe pieces of the mechanism, but they are not statistical recurrence studies. Forum discussions talk about buffers, latency, and whether CSMs can be counted, but I did not find a public, reproducible analysis doing this exact physical-card recurrence comparison.
So I am comfortable saying this:
I have not found a public write-up that does this exact experiment: a six-deck labelled-physical-card IID null, a configurable One2Six-style continuous source, same-physical-card recurrence measurement, and recycle-batch sensitivity showing strong short-return suppression while the mean remains IID-like.
That does not mean no one has ever thought about this. It does mean this appears to be a distinct result in the public material I have found. The individual ideas have ancestors. The specific experiment, metric, implementation, and sensitivity result appear to be mine.
That is worth calling out.
The mean was not the signal
The mean staying near 311 is not surprising. There are still 312 physical cards, and the system is cycling the same physical population. If cards are conserved and the run is long enough, the average recurrence time should stay close to the physical population size.
But that does not make the stream IID.
This is the key lesson:
A process can have the same long-run mean recurrence time as IID and still have a materially different recurrence distribution.
That is the breakthrough in this stage of the project. If I only checked the mean, I would miss the machine. The information was in the shape. The short tail was crushed, the middle caught up, and the long-run mean looked normal.
This is exactly why this project needs distributional diagnostics, not just averages.
What was found
Here is the clean version.
Under the current six-deck configurable One2Six-style source model:
physical-card recurrence is not IID
short physical-card returns are strongly suppressed
the effect survives recycle-batch sensitivity testing
the long-run mean recurrence time remains close to physical IID
fallback ejection was zero in these runs
That is a real finding. It is not the final answer to the blackjack question, but it is not a routine status update either.
This is the first point in the project where the machine model did something structurally interesting under serious measurement. The result is not “the player has an edge.” The result is that the model has physical memory, and that memory shows up clearly in same-card return times.
That is enough to matter.
Why this is a milestone
The earlier work was necessary: build the table, track physical cards, model discards, create the shuffler source, validate IID, fix denominators, write tests, and keep the architecture clean. But most of that was building the measuring instrument.
Now the instrument has measured something.
The result is interesting because it is exactly the kind of subtle structure a weak simulation would miss. The average said nothing. The distribution said plenty.
That is the kind of finding this project was built to detect.
What this does not settle
This still leaves major questions, but they are now better questions than before.
The first is whether the real production machine matches this model closely enough for the result to transfer. The public mechanism trail supports the broad architecture, but not every exact parameter. I do not know the exact production carousel count, shelf behaviour, buffer depth, firmware behaviour, ingestion timing, or model/version differences. That is why the code treats the machine as a configurable model rather than a sacred reconstruction.
The second question is whether physical-card memory becomes rank or value memory. A player does not see one2six-deck-0:T:spades. A player sees T:spades, or more generally a ten-value card, an ace, a low card, or a high-card-rich discard batch.
The third question is game relevance. Even if rank/value structure exists, it must be observable before a decision, large enough to matter, stable across parameters, robust under realistic game timing, and strong enough after variance.
Those are not reasons to downplay today’s result. They are the next gates. The source-level result stands on its own.
Why Stephen How still matters here
Stephen How’s CSM work remains relevant because it is one of the few public attempts to think seriously about CSM state rather than treating the machine as magic randomness. The specific assumptions are not the same as mine, and I am not adopting his conclusions as proof, but the conceptual issue is similar: recently fed cards, buffer depth, muck timing, and windowed counts.
That is exactly the kind of question this project can now test directly. The current result is not a count, not a betting system, and not an EV result. But it supports the broader idea that a CSM-style physical mechanism can have state, and that state can show up in the card stream.
The next step is to determine whether that state appears in player-observable card values.
The code is now GPL licensed
The codebase is now licensed under GPL-3.0-or-later.
That matters to me. This project should not be a set of vague claims about a black box. The assumptions, code, tests, and diagnostics should be inspectable. If I make a mistake, I want it to be findable. If a result survives, I want it to survive because the method is clear, not because the claim is protected by obscurity.
The repository now includes:
full GPLv3 license text
SPDX headers in Python source files
license metadata in pyproject.toml
README license section
project license policy in AGENTS.md
The latest verification state after today’s work was:
python -m pytest 182 passed
python -m ruff check . passed
python -m ruff format --check . passed
python -m mypy src passed
That is also part of the milestone. A simulation project is only interesting if it can keep running as it grows.
Charts are next
The plots are generated, but I am not including them in this article yet. That is a publishing issue, not a simulation issue.
The next short follow-up will include the visual diagnostics:
physical IID recurrence histogram with geometric overlay
One2Six pooled recurrence versus physical IID
tail probability by recycle batch size
tail probability ratio versus physical IID
mean cards-between by recycle batch size
The tables above contain the core result. The charts will make the shape easier to see.
What comes next
The next step is not betting. The next step is observable structure.
The question changes from:
Does the same physical card reappear too quickly or too slowly?
to:
Does the visible composition of recent cards say anything about the next cards?
That means testing rank recurrence, suit recurrence, ten-value recurrence, ace recurrence, low-card recurrence, Hi-Lo rolling windows, recent-discard composition versus next-window composition, and manual-shoe comparison.
Physical memory is interesting. Observable rank/value memory is potentially blackjack-relevant. That is the bridge.
For now, the main result is simple:
In the current six-deck One2Six-style source model, the mean return time looked random. The return distribution did not.
And that is the first real hit.
References and source notes
Part 4 - The Machine Enters the Simulation introduced the current simulation architecture, including the card-source abstraction, physical-card identity, discard timing, and the One2Six-style source.
Part 5 - Validating the Baseline explained the baseline discipline, including why source-level diagnostics come before profit and why recurrence is a geometric waiting-time problem under IID.
ONE2SIX OTS product material describes the device as a continuous shuffler capable of handling up to six decks and continuously shuffling four, five, or six decks. The experiments in this article use six decks only.
US10722779B2 is part of the public patent trail for card handling devices involving feeder paths, compartments, carousel mechanisms, and card movement through a shuffling device.
US8702101B2 is another part of the public patent trail around automatic card shuffler architecture, card handling zones, compartments, and related mechanisms.
Diaconis, Fulman, and Holmes - Analysis of Casino Shelf Shuffling Machines is important prior work showing that mechanical shufflers can be analysed as probability objects. It is related in spirit, but it is not the same experiment as this six-deck continuous-source physical-card recurrence analysis.
Stephen How, Counting CSM Blackjack (+EV) is relevant prior public work on CSM state, buffer depth, muck timing, and windowed counting. I am treating it as a source of hypotheses and framing, not as proof of this project’s model.
Bertsekas and Tsitsiklis, Introduction to Probability, is one of the methodology references for sample-space selection, independence, and waiting-time reasoning.
Wasserman, All of Statistics, is one of the methodology references for the probability/inference framing and statistical diagnostic approach.