-
-
Notifications
You must be signed in to change notification settings - Fork 5.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add missing method for rand(::_GLOBAL_RNG)
#41123
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rfourquet
reviewed
Jun 8, 2021
shirodkara
pushed a commit
to shirodkara/julia
that referenced
this pull request
Jun 9, 2021
rfourquet
added a commit
that referenced
this pull request
Jun 15, 2021
johanmon
pushed a commit
to johanmon/julia
that referenced
this pull request
Jul 5, 2021
rfourquet
added a commit
that referenced
this pull request
Jul 12, 2021
rfourquet
added a commit
that referenced
this pull request
Sep 19, 2023
`GLOBAL_RNG` is a relic from pre-v1.3 when our global RNG was not thread-safe: ``` const GLOBAL_RNG = MersenneTwister() ``` `GLOBAL_RNG` was never really specified, but was referred to in docstrings (of `rand` etc.), and people had to use it in packages in order to provide a default RNG to their functions. So we have to keep defining `Random.GLOBAL_RNG` for the time being. In v1.3, we didn't have anymore a unique global RNG, but instead one per thread; in order to keep code using `GLOBAL_RNG` working, we got this new definition as a clever hack: ``` struct _GLOBAL_RNG <: AbstractRNG end const GLOBAL_RNG = _GLOBAL_RNG() ``` I.e. `GLOBAL_RNG` is just a handle, which refers to the actual threaded-RNG when passed to `rand` functions. This entails defining most function taking a `default_rng()` to also accept `_GLOBAL_RNG`. See #41123, and #41235 which is not even merged. But since v1.7, we have `Random.default_rng()` (our now official way to refer to the default RNG) returning `TaskLocalRNG()`, which is itself a "handle" (singleton). So we can as well redefine `GLOBAL_RNG` to be `TaskLocalRNG()` instead of `_GLOBAL_RNG()`, with the advantage that all the relevant methods are already defined for `TaskLocalRNG`. The only expected difference in behavior is `seed!(GLOBAL_RNG, seed)`, which previously would update `Random.GLOBAL_SEED` (a hack used by `@testset`), but now is equivalent to `seed!(TaskLocalRNG(), seed)`, which doesn't update this global seed. This precise behavior was never documented (`GLOBAL_SEED` is purely internal), so this should be fine.
rfourquet
added a commit
that referenced
this pull request
Sep 22, 2023
`GLOBAL_RNG` is a relic from pre-v1.3 when our global RNG was not thread-safe: ``` const GLOBAL_RNG = MersenneTwister() ``` `GLOBAL_RNG` was never really specified, but was referred to in docstrings (of `rand` etc.), and people had to use it in packages in order to provide a default RNG to their functions. So we have to keep defining `Random.GLOBAL_RNG` for the time being. In v1.3, we didn't have anymore a unique global RNG, but instead one per thread; in order to keep code using `GLOBAL_RNG` working, we got this new definition as a clever hack: ``` struct _GLOBAL_RNG <: AbstractRNG end const GLOBAL_RNG = _GLOBAL_RNG() ``` I.e. `GLOBAL_RNG` is just a handle, which refers to the actual threaded-RNG when passed to `rand` functions. This entails defining most functions taking a `default_rng()` to also accept `_GLOBAL_RNG`. See #41123, and #41235 which is not even merged. But since v1.7, we have `Random.default_rng()` (our now official way to refer to the default RNG) returning `TaskLocalRNG()`, which is itself a "handle" (singleton). So we can as well redefine `GLOBAL_RNG` to be `TaskLocalRNG()` instead of `_GLOBAL_RNG()`, with the advantage that all the relevant methods are already defined for `TaskLocalRNG`. The only expected difference in behavior is `seed!(GLOBAL_RNG, seed)`, which previously would update `Random.GLOBAL_SEED` (a hack used by `@testset`), but now is equivalent to `seed!(TaskLocalRNG(), seed)`, which doesn't update this global seed. This precise behavior was never documented (`GLOBAL_SEED` is purely internal), so this should be fine.
rfourquet
added a commit
that referenced
this pull request
Sep 29, 2023
`GLOBAL_RNG` is a relic from pre-v1.3 when our global RNG was not thread-safe: ``` const GLOBAL_RNG = MersenneTwister() ``` `GLOBAL_RNG` was never really specified, but was referred to in docstrings (of `rand` etc.), and people had to use it in packages in order to provide a default RNG to their functions. So we have to keep defining `Random.GLOBAL_RNG` for the time being. In v1.3, we didn't have anymore a unique global RNG, but instead one per thread; in order to keep code using `GLOBAL_RNG` working, we got this new definition as a clever hack: ``` struct _GLOBAL_RNG <: AbstractRNG end const GLOBAL_RNG = _GLOBAL_RNG() ``` I.e. `GLOBAL_RNG` is just a "handle", which refers to the actual threaded-RNG when passed to `rand` functions. This entails defining most functions taking a `default_rng()` to also accept `_GLOBAL_RNG`. See #41123, and #41235 which is not even merged. But since v1.7, we have `Random.default_rng()` (our now official way to refer to the default RNG) returning `TaskLocalRNG()`, which is itself a "handle" (singleton). So we can as well redefine `GLOBAL_RNG` to be `TaskLocalRNG()` instead of `_GLOBAL_RNG()`, with the advantage that all the relevant methods are already defined for `TaskLocalRNG`. The only expected difference in behavior is `seed!(GLOBAL_RNG, seed)`, which previously would update `Random.GLOBAL_SEED` (a hack used by `@testset`), but now is equivalent to `seed!(TaskLocalRNG(), seed)`, which doesn't update this global seed. This precise behavior was never documented (`GLOBAL_SEED` is purely internal), so this should be fine.
vchuravy
pushed a commit
to JuliaLang/Test.jl
that referenced
this pull request
Oct 7, 2023
`GLOBAL_RNG` is a relic from pre-v1.3 when our global RNG was not thread-safe: ``` const GLOBAL_RNG = MersenneTwister() ``` `GLOBAL_RNG` was never really specified, but was referred to in docstrings (of `rand` etc.), and people had to use it in packages in order to provide a default RNG to their functions. So we have to keep defining `Random.GLOBAL_RNG` for the time being. In v1.3, we didn't have anymore a unique global RNG, but instead one per thread; in order to keep code using `GLOBAL_RNG` working, we got this new definition as a clever hack: ``` struct _GLOBAL_RNG <: AbstractRNG end const GLOBAL_RNG = _GLOBAL_RNG() ``` I.e. `GLOBAL_RNG` is just a "handle", which refers to the actual threaded-RNG when passed to `rand` functions. This entails defining most functions taking a `default_rng()` to also accept `_GLOBAL_RNG`. See JuliaLang/julia#41123, and JuliaLang/julia#41235 which is not even merged. But since v1.7, we have `Random.default_rng()` (our now official way to refer to the default RNG) returning `TaskLocalRNG()`, which is itself a "handle" (singleton). So we can as well redefine `GLOBAL_RNG` to be `TaskLocalRNG()` instead of `_GLOBAL_RNG()`, with the advantage that all the relevant methods are already defined for `TaskLocalRNG`. The only expected difference in behavior is `seed!(GLOBAL_RNG, seed)`, which previously would update `Random.GLOBAL_SEED` (a hack used by `@testset`), but now is equivalent to `seed!(TaskLocalRNG(), seed)`, which doesn't update this global seed. This precise behavior was never documented (`GLOBAL_SEED` is purely internal), so this should be fine.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
domain:randomness
Random number generation and the Random stdlib
kind:bugfix
This change fixes an existing bug
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.
This caused
rand(GLOBAL_RNG)
andrand(copy(GLOBAL_RNG))
to take different paths, leading to a failure in DynamicHMC.jl.