Common Errors in Random Number & Group Picking

The most common random-number mistake is the off-by-one range. People describe a "random number from 1 to 100" and expect exactly 100 candidates, but if the code treats the maximum as exclusive and generates 1 through 99, or the user types 99 believing it includes 100, the pool silently shrinks. The fix is a habit: always state inclusive endpoints, 1–100 means 1 and 100 are both possible, and verify the tool's display confirms the range before the first draw.

Reversed ranges are the second classic. Typing a maximum smaller than the minimum — min 100, max 1 — is a copy-paste slip that some tools silently "fix" by swapping and others reject outright. Silent swapping is dangerous because it hides the mistake; the better behaviour, which the picker uses, is to refuse the reversed range with a clear message. If a generator returns values without complaint when your min exceeds your max, treat that as a red flag about its validation quality.

Requesting more unique values than the range can hold is a guaranteed failure in disguise. With no-repeat enabled, drawing fifty numbers from a range of ten is impossible: there are only ten distinct values. Naive implementations loop forever in this state; well-designed ones detect the mismatch before generating and tell you exactly why. The practical fix is to size the range against the count first — a pool of 50 for a draw of 50, or a draw of 10 from a range of at least 10 — and only then press generate.

Modulo bias is invisible but real. The shortcut Math.floor(Math.random() * n) yields every result in 0..n-1 only when n divides evenly into the generator's output resolution; otherwise, the smaller remainder values are fractionally more likely. For a raffle or a classroom pick the effect is usually harmless, but for statistically exact work, lotteries, or audits it matters. Rejection sampling eliminates the bias entirely, which is the technique the picker implements under the hood — and the reason its draws are worth trusting for serious sampling.

Forgetting that unseeded draws are unreproducible is a quieter but common error. A teacher or organizer runs a draw, saves the screenshot, and later cannot explain the result because there is no seed to replay. If reproducibility matters — and it should for any contest or experiment you might need to defend — supply a seed at draw time and store it with the output. The picker's seeded mode produces an identical sequence for the same seed, so a saved seed plus the range and count fully reconstructs the draw.

In group mode, duplicate names cause the classic "Alex listed twice" problem. The picker treats every non-empty line as a separate member, so two identical lines become two members, which is correct if two people share a name but wrong if the roster was pasted with accidental duplicates. Review the input list before assigning: deduplicate intentional repeats, keep genuine duplicates. The output always shows the member count per group, so a double-counted name is visible the moment you look.

Asking for more groups than names is another structural error. You cannot form four teams from three people and keep every team non-empty, so the picker limits the group count to the number of names and explains why. Relatedly, asking for fewer groups than makes sense for the size — one giant team from twenty names — is technically valid but usually not what the organizer intended. Check that the number of groups you request leaves each group with at least a couple of members.

Whitespace and formatting issues hide in pasted rosters. Trailing spaces turn "Alex " into a different entry than "Alex", and empty lines, if not filtered, create phantom members. The picker trims each line and drops blanks automatically, but it preserves internal spacing and capitalization, so names that differ only by a space or a case remain distinct. Paste from a clean list, review the parsed roster in the output's member counts, and you avoid the phantom-member surprises entirely.

Finally, the meta-error: trusting the result without testing the process. Run one throwaway draw with a low count to confirm the range, repeat policy, and group sizes behave as expected, then perform the real draw. Compare the two and you will catch most of the errors above in thirty seconds. Randomness is cheap to rehearse and expensive to undo after the fact, so the discipline of a practice draw is the cheapest insurance a picker user can buy.