package load altering RNG state

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

package load altering RNG state

Benjamin Tyner
Hello

When loading a package, I'm wondering if it's frowned upon for the
package to alter the state of the random number generator? I guess not,
since the parallel package does it?

    > set.seed(6860)
    > old.seed <- .GlobalEnv$.Random.seed
    > library(parallel)
    > new.seed <- .GlobalEnv$.Random.seed
    > identical(old.seed, new.seed)
    [1] FALSE

I ask because, I found myself writing a custom wrapper around library()
to restore the original RNG state, in order to increase reproducibility.
But now wondering if others would welcome such a feature to be added to
base R? Either something very general like

    preserveRNGstate(library(parallel))

or perhaps an specific enhancement to library itself?

Regards
Ben

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: package load altering RNG state

Henric Winell
Hi,

On 2017-02-07 13:12, Benjamin Tyner wrote:

> Hello
>
> When loading a package, I'm wondering if it's frowned upon for the
> package to alter the state of the random number generator? I guess not,
> since the parallel package does it?

Surprisingly it is not frowned upon, but it *is* a nuisance.  I brought
it up a couple of years ago

http://r.789695.n4.nabble.com/parallel-package-changes-Random-seed-td4686321.html

along with a patch, but was told off...

>
>     > set.seed(6860)
>     > old.seed <- .GlobalEnv$.Random.seed
>     > library(parallel)
>     > new.seed <- .GlobalEnv$.Random.seed
>     > identical(old.seed, new.seed)
>     [1] FALSE
>
> I ask because, I found myself writing a custom wrapper around library()
> to restore the original RNG state, in order to increase reproducibility.
> But now wondering if others would welcome such a feature to be added to
> base R? Either something very general like
>
>     preserveRNGstate(library(parallel))
>
> or perhaps an specific enhancement to library itself?

I would very much welcome a change, but in the light of things it
doesn't seem likely.

Henric Winell


>
> Regards
> Ben
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: package load altering RNG state

Martin Maechler
>>>>> Henric Winell <[hidden email]>
>>>>>     on Tue, 7 Feb 2017 13:37:42 +0100 writes:

    > Hi, On 2017-02-07 13:12, Benjamin Tyner wrote:

    >> Hello
    >>
    >> When loading a package, I'm wondering if it's frowned
    >> upon for the package to alter the state of the random
    >> number generator? I guess not, since the parallel package
    >> does it?

    > Surprisingly it is not frowned upon, but it *is* a
    > nuisance.  I brought it up a couple of years ago

    > http://r.789695.n4.nabble.com/parallel-package-changes-Random-seed-td4686321.html

    > along with a patch, but was told off...

    >>
    >> > set.seed(6860) > old.seed <- .GlobalEnv$.Random.seed >
    >> library(parallel) > new.seed <- .GlobalEnv$.Random.seed >
    >> identical(old.seed, new.seed) [1] FALSE
    >>
    >> I ask because, I found myself writing a custom wrapper
    >> around library() to restore the original RNG state, in
    >> order to increase reproducibility.  But now wondering if
    >> others would welcome such a feature to be added to base
    >> R? Either something very general like
    >>
    >> preserveRNGstate(library(parallel))
    >>
    >> or perhaps an specific enhancement to library itself?

    > I would very much welcome a change, but in the light of
    > things it doesn't seem likely.

    > Henric Winell

Sometimes things change ... and not always for the worse.  I've
found a version of your original patch idea which is very
efficient nice (in my eyes) and still leaves
        system.time(loadNamespace("parallel"))
to round to 0, i.e. needing less than 1 ms.

   --> in R-devel svn rev 72136

Martin

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: package load altering RNG state

Henric Winell
On 2017-02-07 15:59, Martin Maechler wrote:

>>>>>> Henric Winell <[hidden email]>
>>>>>>      on Tue, 7 Feb 2017 13:37:42 +0100 writes:
>
>      > Hi, On 2017-02-07 13:12, Benjamin Tyner wrote:
>
>      >> Hello
>      >>
>      >> When loading a package, I'm wondering if it's frowned
>      >> upon for the package to alter the state of the random
>      >> number generator? I guess not, since the parallel package
>      >> does it?
>
>      > Surprisingly it is not frowned upon, but it *is* a
>      > nuisance.  I brought it up a couple of years ago
>
>      > http://r.789695.n4.nabble.com/parallel-package-changes-Random-seed-td4686321.html
>
>      > along with a patch, but was told off...
>
>      >>
>      >> > set.seed(6860) > old.seed <- .GlobalEnv$.Random.seed >
>      >> library(parallel) > new.seed <- .GlobalEnv$.Random.seed >
>      >> identical(old.seed, new.seed) [1] FALSE
>      >>
>      >> I ask because, I found myself writing a custom wrapper
>      >> around library() to restore the original RNG state, in
>      >> order to increase reproducibility.  But now wondering if
>      >> others would welcome such a feature to be added to base
>      >> R? Either something very general like
>      >>
>      >> preserveRNGstate(library(parallel))
>      >>
>      >> or perhaps an specific enhancement to library itself?
>
>      > I would very much welcome a change, but in the light of
>      > things it doesn't seem likely.
>
>      > Henric Winell
>
> Sometimes things change ... and not always for the worse.  I've
> found a version of your original patch idea which is very
> efficient nice (in my eyes) and still leaves
> system.time(loadNamespace("parallel"))
> to round to 0, i.e. needing less than 1 ms.
>
>     --> in R-devel svn rev 72136

Many thanks for this, Martin!

Henric


>
> Martin
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: package load altering RNG state

Benjamin Tyner
In reply to this post by Martin Maechler
Martin,

Outstanding! This is a most welcome enhancement.

Regards

Ben


On 02/07/2017 09:59 AM, Martin Maechler wrote:

>>>>>> Henric Winell <[hidden email]>
>>>>>>      on Tue, 7 Feb 2017 13:37:42 +0100 writes:
>      > Hi, On 2017-02-07 13:12, Benjamin Tyner wrote:
>
>      >> Hello
>      >>
>      >> When loading a package, I'm wondering if it's frowned
>      >> upon for the package to alter the state of the random
>      >> number generator? I guess not, since the parallel package
>      >> does it?
>
>      > Surprisingly it is not frowned upon, but it *is* a
>      > nuisance.  I brought it up a couple of years ago
>
>      > http://r.789695.n4.nabble.com/parallel-package-changes-Random-seed-td4686321.html
>
>      > along with a patch, but was told off...
>
>      >>
>      >> > set.seed(6860) > old.seed <- .GlobalEnv$.Random.seed >
>      >> library(parallel) > new.seed <- .GlobalEnv$.Random.seed >
>      >> identical(old.seed, new.seed) [1] FALSE
>      >>
>      >> I ask because, I found myself writing a custom wrapper
>      >> around library() to restore the original RNG state, in
>      >> order to increase reproducibility.  But now wondering if
>      >> others would welcome such a feature to be added to base
>      >> R? Either something very general like
>      >>
>      >> preserveRNGstate(library(parallel))
>      >>
>      >> or perhaps an specific enhancement to library itself?
>
>      > I would very much welcome a change, but in the light of
>      > things it doesn't seem likely.
>
>      > Henric Winell
>
> Sometimes things change ... and not always for the worse.  I've
> found a version of your original patch idea which is very
> efficient nice (in my eyes) and still leaves
> system.time(loadNamespace("parallel"))
> to round to 0, i.e. needing less than 1 ms.
>
>     --> in R-devel svn rev 72136
>
> Martin

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel