Probability Simulator — See Randomness in Action

A probability simulator is a tool that runs a large number of virtual random draws against a configured probability space and reports the resulting distribution. For a weighted spin wheel, that means: define the wheel (entries plus weights), specify how many spins to simulate, and the simulator tells you which entries won, how often, and how that compares to the theoretical probability each one should have had.

The point isn't to predict the future — randomness by definition has no memory of past draws. The point is to make the math of probability visible. Most people's intuition for randomness is shaky: we underestimate how much variance shows up in small samples, and we overestimate how 'patterned' random sequences look. Running 100, 1,000, and 10,000 simulated draws against the same wheel and seeing the distributions move from messy to clean is the fastest way to repair that intuition.

This particular simulator runs in your browser — nothing is sent to a server. The wheel's entries, the random draws, and the resulting analysis all happen client-side using the browser's cryptographic random number generator. Results are available a fraction of a second after you click Run.

Behind any weighted spinner is a small piece of math called cumulative weighted random selection. The algorithm is short enough to describe in two sentences: convert each entry's weight into a cumulative range, then pick a random number inside the total and find which range it falls into.

Concrete example. The wheel has Alice (weight 3), Bob (weight 2), Carol (weight 1) — total weight 6. The cumulative array is [3, 5, 6]. To pick a winner: generate a uniformly random number in [0, 6). If it's 0, 1, or 2 → Alice (the first range). If 3 or 4 → Bob. If 5 → Carol. Over many draws, Alice wins ~50% of the time (3 out of 6), Bob ~33% (2 of 6), Carol ~17% (1 of 6).

The simulator runs exactly this algorithm for each virtual spin, using the same crypto.getRandomValues call the live wheel uses. So when the simulator reports 'Alice won 50.1% of the time across 10,000 spins', that's a direct prediction of what the live wheel will do over many real spins — the underlying math is identical.

The law of large numbers is the formal statement of an intuition you've probably half-formed already: as you increase the number of random trials, the observed average gets closer to the true expected value. For a spin wheel, that means: with enough spins, each entry's actual win rate approaches its theoretical win rate (weight divided by total weight).

But 'enough' is doing a lot of work in that sentence. With four equally-weighted names and only 4 spins, you'd expect each name to win once — but actually getting one win per name happens only about 9% of the time. Most 4-spin runs are lopsided. Even at 100 spins, you'll typically see 5-10% variance per entry. By 10,000 spins, variance drops to fractions of a percent and the distribution looks almost identical to the theoretical one.

This simulator lets you see that convergence happen. Run the same wheel at 100 spins three times in a row — the distributions will all look different. Run it at 10,000 spins three times — they'll all look the same. That's the law of large numbers in action: random variance averages out as the sample grows.

A perfectly fair coin can land heads ten times in a row. A perfectly weighted raffle wheel can draw the same winner three times in a row. Neither is rigged — they're both completely consistent with random behaviour over a small sample. But our pattern-detecting brains see those streaks as signals that something is off.

This is the source of most 'is your raffle wheel really random?' complaints from audiences. After a sub giveaway streamer draws the same name twice in 50 spins, half of chat is convinced the draw is broken. The simulator is the answer: run 50 spins against the same wheel and watch how often you see double-draws. The answer, for a 20-entry wheel, is 'in about 73% of 50-spin runs'. Doubles are the expected behaviour, not the exception.

Teachers can use this to teach the gambler's fallacy from the opposite direction. After heads-heads-heads-heads on four coin flips, the chance of the next flip being heads is still 50%. Coins have no memory. Spin wheels have no memory. The simulator shows this concretely: weight the wheel however you like, and the next spin's probability is whatever the static weights say it is, regardless of what just happened.

The standard classroom probability lesson is: define a probability space (a fair die, a weighted spinner, a deck of cards), compute the theoretical probability of an outcome, and then maybe roll the die a few times to compare. The 'few times' step is the weakest link — six rolls of a die never look fair, and students walk away mildly confused about whether the math was right.

The simulator replaces 'a few rolls' with 100, then 1,000, then 10,000. The visual change between those three is dramatic: a 100-spin bar chart looks chaotic, a 1,000-spin chart is recognisable, a 10,000-spin chart is indistinguishable from the theoretical ideal. Students see convergence happen instead of being told about it.

Lesson plan ideas: (1) compute expected probabilities for a weighted wheel as a class, then run 10,000 spins and compare each prediction to the result. (2) Run the same 50-spin simulation three times back to back and ask students to predict whether each entry will win more or less than its expected share. They'll be wrong about half the time, which is the lesson. (3) Build a 'fair' wheel and a 'rigged' wheel (one entry weighted 50% higher than the others) and have students identify which is which based on the chart alone — at 100 spins they'll struggle, at 10,000 the difference is obvious.

If you run raffles, giveaways, or weighted draws in front of an audience, the simulator is a tool for proving fairness before the draw rather than defending it after. Pre-event workflow: build the wheel exactly as it will appear at the event (real ticket names, real weights), run 10,000 simulated draws, and confirm the distribution matches the weights you advertised.

Then save the simulation result as CSV or JSON. If anyone later asks 'were the multi-entry tickets really getting 5× the chance?', you have data showing the simulated 10k-spin distribution puts those names at almost exactly 5× the win rate. You're not proving the specific draw was fair (that's just one spin) — you're proving the WHEEL is fair, which is what audiences actually care about.

For audited corporate raffles, pair the simulator with a screen recording of the live draw. The pre-draw simulation establishes the wheel's correctness; the recorded draw shows the actual outcome. Together they form a transparent audit trail that's stronger than any single statement of 'we used a random picker'.

10,000 is the sweet spot for the simulator's purpose. At that count, weighted distributions converge to within a fraction of a percent of their expected values — enough resolution to demonstrate convergence, audit fairness, or check a homework prediction. Pushing further (100k, 1M) gets you slightly tighter convergence but at increasing UI cost and with diminishing pedagogical value.

The cap also matters for the export: a 10,000-spin CSV has a clean per-entry summary (10-50 rows depending on entry count). A million-spin CSV would have the same summary, but generating it would take longer and the data wouldn't tell the user anything 10,000 didn't already.

The simulator runs in a Web Worker for runs above 5,000 spins, so even the 10k case doesn't block the main UI. A 10k simulation against a 20-entry wheel completes in well under 50ms on a modern laptop and under 200ms on a low-end phone — fast enough to feel instant.