Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/calvinsprouse/dice-equivalence
A demonstration and extension of a Stand-up Maths video.
https://github.com/calvinsprouse/dice-equivalence
dice latex math matplotlib numpy probability python
Last synced: 19 days ago
JSON representation
A demonstration and extension of a Stand-up Maths video.
- Host: GitHub
- URL: https://github.com/calvinsprouse/dice-equivalence
- Owner: CalvinSprouse
- Created: 2024-09-11T18:46:38.000Z (2 months ago)
- Default Branch: main
- Last Pushed: 2024-09-11T20:34:33.000Z (2 months ago)
- Last Synced: 2024-10-31T13:04:25.615Z (19 days ago)
- Topics: dice, latex, math, matplotlib, numpy, probability, python
- Language: Jupyter Notebook
- Homepage:
- Size: 341 KB
- Stars: 0
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# A tl;dr summary of [The unexpected probability result confusing everyone by Stand-up Maths](https://youtu.be/ga9Qk38FaHM)
Let $n,m \in \mathbb{Z}^+$. Let $\text{rand}(S)$, where $S\subseteq \mathbb{R}$, return a random number from a uniform distribution on the elements of $S$.
Let $\text{d}m$ refer to a dice with sides 1 through $m$ such that rolling the dice produces a uniformly distributed random integer in the inclusive interval $[1,m]$. Then, let $n\text{d}m$ refer to a set of $n$ random numbers produced by $\text{d}m$.
Taking the maximum of the set $n\text{d}m$ is equivalent to taking the $n$th root of a random real number on the interval $[1,m^n]$ then rounding to the nearest integer;$$\text{max}(n\text{d}m) \equiv \left\lceil \text{rand}([1,m^n]) ^{1/n}\right\rceil .$$
Similarly,
$$\text{min}(n\text{d}m) \equiv \left\lceil 1 - \left(1 - \frac{\text{rand}([1,m^n])}{m^n}\right)^{1/n} \right\rceil .$$
Also notice in the figures, specifically the generation time comparisons, that the equivalent algorithm offers significant time savings *in unrealistic numbers of dice* and more importantly no significant increase in computational cost at *unrealistic* numbers of dice.
It's not rigorous, but it's fine.