Why a Spinning-Wheel Picker Can Quietly Drift Away From Equal Odds
A wheel picker with seven equally intended slices, each meant to span exactly 360 ÷ 7 ≈ 51.43°, can end up with alternating 51° and 52° slices if its code rounds each boundary to the nearest whole degree — a small change that shifts one slice’s true selection probability from 14.29% to 14.44% and another’s down to 14.17%, a gap invisible on screen but real in the underlying odds.
A worked example with numbers
Suppose a wheel splits 360° evenly among seven labelled slices. The ideal cumulative boundaries, at exact multiples of 360/7, fall at approximately 0°, 51.43°, 102.86°, 154.29°, 205.71°, 257.14°, 308.57°, and 360°. If the rendering or hit-testing code rounds each of those boundaries to the nearest whole degree instead of keeping the fractional value, they become 0°, 51°, 103°, 154°, 206°, 257°, 309°, and 360° — and the width of each slice, found by subtracting consecutive boundaries, comes out as 51°, 52°, 51°, 52°, 51°, 52°, and 51°, alternating instead of staying uniformly at 51.43°. Converting those widths to probabilities (width ÷ 360) gives four slices at 51°/360 ≈ 14.17% and three slices at 52°/360 ≈ 14.44%, instead of the intended 14.29% for all seven — a small, structural, and entirely avoidable bias introduced purely by rounding boundaries independently rather than computing each one from the exact fractional formula.
How to set the rule before the result
The fix is to compute every boundary from the exact fractional angle — index × 360 / N — and compare a landed angle against those unrounded boundaries at selection time, only rounding for display purposes, such as drawing the dividing lines, never for deciding which slice was actually hit. To verify a specific wheel implementation is doing this correctly, log the raw stopping angle for a large number of simulated spins — not just the resulting label — and check whether the recorded angles cluster into the expected width for each slice; a slice that consistently receives more landings than its neighbours, across thousands of logged spins, indicates its underlying boundary math, not its animation, needs fixing.
Common mistakes that change the odds or the process
A common mistake is assuming a wheel’s odds are fair because its slices “look the same size” in a screenshot — a one-degree difference between adjacent slices is not visible to the eye at any normal wheel size, so a visual inspection alone cannot catch this class of bug. A second mistake is assuming the bias only appears with an odd or unusual number of slices; a wheel with 12 or 24 slices divides 360 evenly with no fractional remainder at all, so those particular counts are naturally immune to this specific rounding bug, which can make a developer wrongly conclude the rounding approach is safe in general after only testing a favourable slice count. A third mistake is fixing the rounding in the drawing code but leaving the old rounded values in the hit-testing code that actually decides the result — the two code paths can drift apart during a refactor, leaving a wheel that visually redraws correctly while still selecting from the old, biased boundaries underneath.
Where this method stops being appropriate
This specific bias comes from rounding angle boundaries to whole-degree (or otherwise coarse) values; a wheel whose code keeps boundaries as unrounded floating-point angles throughout does not have this particular problem, though floating-point arithmetic can introduce its own much smaller rounding noise, typically many orders of magnitude below one degree and not practically detectable. This analysis also assumes the physical or animated spin itself lands on a uniformly distributed angle across the full 360°; a spin whose deceleration curve is not spatially uniform — for instance, one more likely to stop near certain angles because of how the easing function is implemented — introduces a separate, potentially larger bias that boundary-rounding fixes alone would not address.
How the random source fits into the rule
MDN’s Math.random reference documents the uniform 0-to-1 interval most spin-angle calculations ultimately derive from before being scaled to 360° and divided among labelled slices, the numeric foundation the boundary-rounding bug above distorts.
Exact vs. rounded boundaries for a seven-slice wheel
| Slice | Exact boundary (°) | Rounded boundary (°) | Resulting width | Resulting probability |
|---|---|---|---|---|
| 1 | 0.00 | 0 | 51° | 14.17% |
| 2 | 51.43 | 51 | 52° | 14.44% |
| 3 | 102.86 | 103 | 51° | 14.17% |
| 4 | 154.29 | 154 | 52° | 14.44% |
| 5 | 205.71 | 206 | 51° | 14.17% |
| 6 | 257.14 | 257 | 52° | 14.44% |
| 7 | 308.57 | 309 | 51° | 14.17% |
Every rounded boundary is off from its exact value by less than half a degree individually, yet the resulting widths still land unevenly, because rounding each boundary independently does not preserve the equal spacing between them.
A second case: a 37-slice wheel, where the drift compounds further
A wheel with 37 equally intended slices — a common count for a roulette-style novelty wheel — has an ideal slice width of 360 ÷ 37 ≈ 9.7297°. Rounding each cumulative boundary to the nearest whole degree produces a mix of 10° and 9° slices across the full circle: working through all 37 cumulative boundaries this way yields 26 slices at 10° (10/360 ≈ 2.778%) and 11 slices at 9° (9/360 = 2.5%), versus the intended 360/37 ≈ 2.703% for every slice. The gap here — 2.778% versus 2.5%, a relative difference of about 11% between the two groups — is noticeably larger than the seven-slice case, because a smaller ideal slice width means whole-degree rounding represents a larger fraction of each slice’s intended size.
How to tell this apart from an intentionally weighted wheel
Not every unequal-looking wheel is broken — a wheel deliberately built with different-sized slices to represent different weighted probabilities is working exactly as designed, and its unequal widths are the point, not a bug. The distinguishing question is whether the widths were chosen deliberately, as an explicit weighting, or emerged as an unintended side effect of how boundaries happened to be rounded during implementation; a wheel’s configuration screen should make that distinction explicit, stating either “N equal slices” or naming the specific weight assigned to each label, so a user comparing the visual wheel to its stated odds has something concrete to check it against.
A related but separate bug shows up in explicitly weighted wheels, where slice sizes are meant to reflect stated percentages rather than equal shares. Three slices weighted 33.3%, 33.3%, and 33.4% should sum to exactly 100% and 360°, but converting each percentage to degrees independently — 33.3% × 360 = 119.88°, applied three times — can leave a small leftover or shortfall after rounding, the same class of error as the whole-degree boundary rounding described above, just triggered by percentage-to-angle conversion instead of boundary-index rounding. The fix is the same in spirit: compute the last slice’s angle as whatever remains after the earlier slices are placed, rather than rounding every slice independently and hoping the errors cancel out.