Export GLOBAL_RNG

[nbecker]

http://docs.julialang.org/en/latest/stdlib/numbers/?highlight=rand#Base.rand refers to GLOBAL_RNG, but the value is not exported.

My use case is I write a random number generator (specialized for my use), and the underlying AbstractRNG is passed in to the constructor, with GLOBAL_RNG as the default value.

Shouldn't GLOBAL_RNG be exported?

[andreasnoack]

Most users shouldn't use GLOBAL_RNG directly so I don't think it should be exported.

[cstjean]

Is there a recommended way of writing reproducible random functions that doesn't use GLOBAL_RNG?

[ViralBShah]

Why not just create a non-global version with

RNG = MersenneTwister(seed)

And then pass that around? For convenience if necessary, you can always pass in Base.GLOBAL_RNG, but we want to move away from that as we do more multi-threaded stuff and so on and hence not commit to it as an exported API.

[ViralBShah]

Closing for now- can reopen the issue if necessary.

[rfourquet]

I would tend to think that many users who create custom types and need to work with random objects of those types would have to use GLOBAL_RNG, but indeed this should wait till the multi-threaded stuff is fixed.

[stevengj]

The reason to export this (as @nbecker indicated) would be if you want to define a random function that takes an optional rng, like the Base functions. You want it to default to GLOBAL_RNG:

myrandomstuff(rng::AbstractRNG, ...) = ...
myrandomstuff(...) = myrandomstuff(Base.Random.GLOBAL_RNG, ...)

It's annoying to have to qualify Base.Random.GLOBAL_RNG here.

See also the mailing list: https://discourse.julialang.org/t/performance-issue-with-specifying-random-number-generator/1076

[ViralBShah]

I am ok with exporting it, but it seems like it will be one of the first things to break once we have decent multi-threading support. The reasoning to keep it hidden was to be explicit about it.

If there is demand for this, we can go for convenience for now and deal with threading whenever that happens. I assume exporting GLOBAL_RNG in the workspace is what one wants here.

[stevengj]

Won't GLOBAL_RNG be some kind of thread-local variable at some point?

[ViralBShah]

Probably.

[tkelman]

that would likely make GLOBAL_RNG a misnomer when it happens

[JeffBezanson]

I think needing a default RNG argument is rare enough that GLOBAL_RNG does not actually need to be exported. In fact it is already exported from the Random module, which I think is enough (you can do using Base.Random if you're using this a lot). Exporting things from Base that are also exported from a submodule I think should be avoided.