Julia: 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.

[stevengj]

GLOBAL_RNG is used in 7 packages at the moment. I'm not sure I understand the principle of not "exporting things from Base that are also exported from a submodule" ... we do this with tons of functions already (rand and eig, for example).

At the very least, I feel that GLOBAL_RNG should already be documented as the default rng of rand etcetera ... it is seems wrong to have to dig into undocumented Julia internals if you want to write random-number routines that take an optional rng like in Base. And it is a short step from documenting it to exporting it.

[JeffBezanson]

Well, this would be with an eye to moving Random to a package.

[stevengj]

If we moved Random to a package (not, I hope, before we have a default-packages/batteries-included mechanism in place), at that point we will also stop exporting rand and friends. So that doesn't seem to affect the question of whether we should document/export GLOBAL_RNG now.

[rfourquet]

I think we should close this one, writing Random.GLOBAL_RNG is not so bad, and its use must be quite rare (it's not needed when defining new rand methods for example).

[KristofferC]

Ok.

[StefanKarpinski]

I believe we now export Random.default_rng(), so this should be closed in any case.