How random is xkcd? (2015)

Original Article ↗ Hacker News Discussion ↗

Complaints about xkcd’s “random comic” button highlight a broader gap between mathematically correct randomness and what users expect when they press “random” or “shuffle.” Commenters contrast independent random sampling (which naturally produces streaks and duplicates) with deck-style shuffling that cycles through all items once, and share similar stories from music players, video games, and apps that quietly bias their algorithms to “feel” fair or novel. Others dive into statistical test suites, RNG quality, and well-known systems like NIST STS and TestU01, noting that both human intuition and flawed tooling can make judging true randomness surprisingly tricky.

Randomness vs Perceived Fairness

  • Many commenters note that users complaining about XKCD’s “Random” button actually want novelty, not mathematical randomness.
  • People informally expect “random without replacement”: no repeats until all items are seen, or at least strong bias toward unseen items.
  • Human pattern-seeking makes true randomness feel “wrong” when it produces streaks or repeats; this is compared to gambler’s fallacy and other well-known intuitions.
  • Several argue designers should optimize for user expectations, not purity of probability theory; others defend keeping technical correctness even if users misinterpret it.

Random vs Shuffle in Media and UX

  • Strong thread on “random sample” vs “random shuffle”:
    • Sample: pick uniformly from full set each time, allowing repeats.
    • Shuffle: generate a random permutation, then play through it once.
  • Users of music players (Spotify, iPods, CD/MP3 players) report frequent repeats and “stuck on favorites,” judging this as broken.
  • Suggestions include:
    • Track per-user history and exclude or downweight recently seen items.
    • Use weighted or structured algorithms (chunks, artist/tempo spacing, format-preserving encryption tricks).
  • Some insist “shuffle should be like a deck of cards,” others want bias toward “songs not heard in a while.”

Game Design and Biased Randomness

  • Discussion references strategy and RPG games that adjust randomness to “feel fair,” e.g.,:
    • Limiting floods/droughts in Tetris via bag-based randomizers.
    • “Karmic dice” that compensate for recent streaks.
  • Debate over whether players are “irrational” or whether simplistic probabilistic models ignore relevant context (large battles, multiple hits, etc.).

Statistical Discussion and Testing

  • Clarifications on what “almost as many ones as zeros” means:
    • Proportion tends to 50/50; absolute difference typically grows like √n.
  • References to birthday paradox and coupon collector to explain duplicate comics and difficulty of seeing all comics via random.
  • Some commenters run experiments:
    • /dev/urandom over XKCD index range: counts cluster around expected frequencies.
    • XKCD random IDs fed into NIST STS: segfaults and at least one failed test (FFT), highlighting both tool fragility and nontrivial structure in the bitstream.
  • Mention that NIST STS and DIEHARD are seen as older; TESTU01 cited as more modern.

XKCD-Specific Implementation Notes

  • XKCD’s random cannot return comic 404 by design.
  • Multiple commenters suggest a per-user shuffled deck of comic IDs (with cookies or local storage) as a good compromise, though tracking concerns are noted.
  • Some humor about XKCD’s own “4” random-number joke and about intentionally non-random behavior for certain referrers.