Random Number Generator

It is not `Math.random()`. Every draw calls `crypto.getRandomValues()` from the W3C Web Cryptography API (Recommendation 26 January 2017), which pulls bytes from the operating-system entropy pool (Linux `/dev/urandom`, macOS Security framework, Windows `BCryptGenRandom`) — the same source modern password managers and TLS handshakes use. `Math.random()` is fast but is implemented in V8 (Chrome, Node, Edge) and SpiderMonkey (Firefox) as the xorshift128+ algorithm (Vigna 2014; V8 switched to it in v4.9.41 with Chrome 49 stable in March 2016, replacing MWC1616) — it passes the BigCrush statistical battery but is not cryptographically secure and would be the wrong primitive for a tool that issues lottery numbers, raffle picks, or session tokens.

Modulo bias is the small but systematic skew that appears when you take an integer from a uniform range and reduce it mod N where N does not divide the source range evenly. The underlying source here is a 32-bit unsigned integer (range 0..2³²−1). If you ask for a number in 1..100, naive `r % 100` gives every value in 0..95 a probability of 42,949,673 mappings out of 2³² and every value in 96..99 only 42,949,672 mappings — the lower numbers are slightly more likely. The per-low-value excess is 1/2³² ≈ 1 in 4.3 billion, invisible for a coin flip but cumulative across millions of draws (lottery-grade applications, security-token issuance). The fix is rejection sampling: draw, check whether the value falls in the largest multiple of N that fits, retry if not. This tool's `randInt(n)` does exactly that — the expected number of retries is bounded by 2 regardless of N, so the cost is negligible.

Re-roll-on-duplicate (the obvious approach) becomes pathologically slow as the draw count approaches the range size — drawing the last few unique numbers from 1..100 requires on average about 519 draws for all 100 distinct (the coupon-collector limit, n · H_n ≈ 100 × 5.187) and biases the late draws because duplicates skew the empirical distribution. Fisher-Yates (Knuth's Algorithm P from the 1969 Art of Computer Programming Vol 2 §3.4.2, in-place adaptation by Durstenfeld CACM 1964 of the original Fisher & Yates 1938 pencil-and-paper procedure) generates a uniformly random permutation of the full pool in O(range) time and O(range) space, then takes the first N elements. Every permutation is equally likely, every unique-only result set is equally likely, and the runtime stays linear in the range size regardless of how many you draw.

For low-stakes (raffle at the office, classroom seed assignment, A/B test bucket, picking a winner from a comment thread) this tool's `crypto.getRandomValues()` source is more than enough — same primitive RFC 4086 (Eastlake/Schiller/Crocker BCP 106 June 2005) recommends for non-adversarial cryptographic key generation. For regulated lotteries (state-licensed gaming, securities-trading random sampling, clinical-trial randomization) the rule is procedural, not statistical: regulators require an audit trail (logged seeds, witnessed draws, third-party hash chains) and a hardware RNG with periodic statistical testing (NIST SP 800-22, FIPS 140 module validation), neither of which a client-side browser tool can provide. Use this for everyday random picks; use a regulated audited service or a notarized physical draw for anything legally binding.

This tool generates integers only — that is what `randInt(maxExclusive)` produces from `crypto.getRandomValues()` plus rejection sampling. The internal cap is 2³² because the underlying entropy buffer is a Uint32Array; ranges up to about 4.29 billion work natively, beyond that you would need a multi-word draw which this tool does not expose. For floating-point random numbers in [0, 1) the `rand()` helper in `src/lib/random.ts` divides a Uint32 by 2³², giving 32 bits of fractional precision — enough for most simulations but not the full 53 bits of a JavaScript double (the workaround is `crypto.getRandomValues()` with a `BigUint64Array` for 64-bit doubles). Negative ranges, reversed `min/max`, and quantities larger than the integer range are handled by swapping endpoints and clamping the count automatically.