MAINT: stats.qmc: transition to rng (SPEC 7) #21931
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Reference issue
Toward gh-21833
What does this implement/fix?
To prepare for the deprecation and removal of
seed
and its legacy behavior fromstats.qmc
classes., this allows for use of the new keywordrng
alongsideseed
.Additional information
Note that when the
_transition_to_rng
decorator receives an integer as therng
argument, it normalizes it usingdefault_rng
before passing it to the wrapped function. Also, if aQMCEngine
is passed anp.random.default_rng
directly, it doesn't use it; rather, it spawns a new RNG from it. Therefore, with the decorator in place, both of the following happen in sequence: therng
argument is always normalized, and a new Generator is spawned from it.So as-written, if we want to preserve the stream of numbers when the
_transition_to_rng
decorator is removed, we would always need to normalize the argumentrng
argument withdefault_rng
AND spawn a new Generator from that; we would not keep the current logic that "if the argument is an instance ofGenerator
, spawn; otherwise, normalize".There is no problem with this; it's just a bit peculiar. A motivated individual is welcome to adjust the current implementation after this PR merges if this is not the desired long-term behavior.