Skip to content
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 1 commit into from
Jun 9, 2021
Merged

Conversation

JeffBezanson
Copy link
Sponsor Member

This caused rand(GLOBAL_RNG) and rand(copy(GLOBAL_RNG)) to take different paths, leading to a failure in DynamicHMC.jl.

@JeffBezanson JeffBezanson added domain:randomness Random number generation and the Random stdlib kind:bugfix This change fixes an existing bug labels Jun 7, 2021
@vtjnash vtjnash added the status:merge me PR is reviewed. Merge when all tests are passing label Jun 7, 2021
stdlib/Random/src/RNGs.jl Outdated Show resolved Hide resolved
stdlib/Random/src/RNGs.jl Show resolved Hide resolved
@JeffBezanson JeffBezanson merged commit 482d0ac into master Jun 9, 2021
@JeffBezanson JeffBezanson deleted the jb/1argrand branch June 9, 2021 01:28
shirodkara pushed a commit to shirodkara/julia that referenced this pull request Jun 9, 2021
@DilumAluthge DilumAluthge removed the status:merge me PR is reviewed. Merge when all tests are passing label Jun 18, 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 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
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants