QuantEcon / QuantEcon/QuantEcon.py
DISCUSS: Migration path from legacy RandomState to NumPy Generator
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 2.4k
- Forks
- 2.3k
- Avg merge
- 3d 3h
- Merged PRs (30d)
- 3
Description
The decision needed
Our RNG plumbing is the 2015-era scikit-learn idiom: check_random_state (util/random.py) normalizes to np.random.RandomState, reaches into np.random.mtrand._rand for the global instance, and rng_integers exists solely to bridge RandomState/Generator signature differences. NumPy has recommended Generator/default_rng since 1.17 (2019): the actively developed API, faster bit generators, better streams. We accept Generator today, but every internal default and documented example takes the legacy path.
This is a decision, not a patch, because reproducibility is the product: for integer seeds, default_rng(seed) and RandomState(seed) produce different streams, so a silent default switch changes every seeded simulation result in downstream research and the QuantEcon lectures.
Questions for this thread
- Do we migrate defaults at all, or only document
Generatoras the preferred input? - If we migrate: flag-day at a major-ish version with a loud changelog, or a transition period where integer seeds emit a
FutureWarningnaming the change date? - What do the lecture repositories need from us (coordination, pinned examples)?
- Does
check_random_stategrow adefault="generator"parameter, or do we adoptnp.random.default_rngpassthrough plusspawnfor parallel paths?
Suggested outcome
A short policy (target version, warning strategy, docs plan) recorded here, then this thread closes and spawns the implementation issue. Related: the vendoring of rng_integers (this milestone) is worth doing first regardless; a completed migration eventually deletes the vendored copy too.
From the July 2026 technical-debt audit (AI-assisted; claims verified against 28d4b3b on 2026-07-25).
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading util/random.py, especially check_random_state and rng_integers, then review the reproducibility concern around RandomState versus Generator. Compare the migration and documentation options raised in the four questions, including the lecture repositories and vendored rng_integers. Done means agreeing on a short policy covering the target version, warning strategy, and docs plan, then opening a separate implementation issue.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100