similar to: R-devel RNG change

Starting with example Wichmann-Hill code from Brian Ripley I have been playing with a set of programs for getting the same random sequences from R and Splus. A copy is included below along with a test (which works in Solaris with R and Splus 3.3). The approach is somewhat different from the usual problems on this list as I am trying to get the same results from Splus as I get from R. However,

On Sun, Mar 4, 2018 at 3:23 PM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > On 04/03/2018 5:54 PM, Henrik Bengtsson wrote: >> >> The following helps identify when .GlobalEnv$.Random.seed has changed: >> >> rng_tracker <- local({ >> last <- .GlobalEnv$.Random.seed >> function(...) { >> curr <- .GlobalEnv$.Random.seed

On 04/03/2018 5:54 PM, Henrik Bengtsson wrote: > The following helps identify when .GlobalEnv$.Random.seed has changed: > > rng_tracker <- local({ > last <- .GlobalEnv$.Random.seed > function(...) { > curr <- .GlobalEnv$.Random.seed > if (!identical(curr, last)) { > warning(".Random.seed changed") > last <<- curr

The following helps identify when .GlobalEnv$.Random.seed has changed: rng_tracker <- local({ last <- .GlobalEnv$.Random.seed function(...) { curr <- .GlobalEnv$.Random.seed if (!identical(curr, last)) { warning(".Random.seed changed") last <<- curr } TRUE } }) addTaskCallback(rng_tracker, name = "RNG tracker") EXAMPLE: >

Thank you, everybody, who replied! I appreciate your valuable advise! I will move the location of the set.seed() command to after all packages have been installed and loaded. Best regards, Gary Sent from my iPad > On Mar 4, 2018, at 12:18 PM, Paul Gilbert <pgilbert902 at gmail.com> wrote: > > On Mon, Feb 26, 2018 at 3:25 PM, Gary Black <gwblack001 at sbcglobal.net> >

As some of you know, we have been thinking of allowing the possibility of a CHOICE of the kind of random number generator (=: RNG) to use in R. The current R-release snapshot even has some code in it; however, this will be changed quite a bit. Here is a kind of informal RFC (request for comments / request for criticism / ..): 1a. With the new scheme, we still want that save(..) &

On 7 February 2015 at 19:52, otoomet wrote: | random numbers. For instance, can I be sure that | set.seed(0); print(runif(1)); print(rnorm(1)) | will always print the same numbers, also in the future version of R? There Yes, pretty much. I've been lurking here over fifteen years, and while I am getting old and forgetful I can remember exactly one such change where behaviour was changed,

On Mon, Feb 26, 2018 at 3:25 PM, Gary Black <gwblack001 at sbcglobal.net> wrote: (Sorry to be a bit slow responding.) You have not supplied a complete example, which would be good in this case because what you are suggesting could be a serious bug in R or a package. Serious journals require reproducibility these days. For example, JSS is very clear on this point. To your question >

Hi All, I have k identical parallel pieces of code running, each using n.rand random numbers.? I would like to use the same RNG (for now), and set the seeds so that I can guarantee that there are no overlaps in the random numbers sampled by the k pieces of code.? Another side goal is to have reproducibility of my results.? In?the past I have used C with SPRNG for this task, but I'm hoping

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

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

>>>>> Henric Winell <nilsson.henric at gmail.com> >>>>> 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

I would like to suggest a modification of initial scrambling of the seed in RNG_Init (called from do_setseed). The modified code is equivalent, but faster. Patch against R-devel_2007-09-22 follows --- R-devel-orig/src/main/RNG.c 2007-09-02 07:49:35.000000000 +0200 +++ R-devel-modif/src/main/RNG.c 2007-09-23 10:51:59.234566440 +0200 @@ -216,8 +216,8 @@ BM_norm_keep = 0.0; /* zap Box-Muller

On 30 August 2016 at 18:29, Duncan Murdoch wrote: | I don't see evidence of a bug. There have been several versions of the | MT; we may be using a different version than you are. Ours is the | 1999/10/28 version; the web page you cite uses one from 2002. | | Perhaps the newer version fixes some problems, and then it would be | worth considering a change. But changing the default RNG

>>>>> Berwin A Turlach >>>>> on Tue, 5 Mar 2019 16:54:09 +0800 writes: > G'day all, > I have daily scripts running to install the patched version of the > current R version and the development version of R on my linux box > (Ubuntu 18.04.2 LTS). > The last development version that was successfully compiled and >

In a vanilla R 2.14.0 GUI session (on Windows XP SP3): > library(parallel) > cl<-makePSOCKcluster(2) > RNGkind() [1] "Mersenne-Twister" "Inversion" > clusterSetRNGStream(cl) > RNGkind() [1] "L'Ecuyer-CMRG" "Inversion" > stopCluster(cl) Is it intentional that clusterSetRNGStream() changes the RNG kind in the master process?

I wouldn't trust the C++ generator to be as good if you seed it this way as if you just seeded it once with your phone number (or any other fixed value) and let it run, because it's probably never been tested to be good when run this way. Is it good enough for the way you plan to use it? Maybe. Duncan Murdoch On 30/07/2020 3:05 p.m., Tommy Jones wrote: > Hi, > > I am

Hi, I am constructing a function that does sampling in C++ using a non-R RNG stream for thread safety reasons. This C++ function is wrapped by an R function, which is user facing. The R wrapper does some sampling itself to initialize some variables before passing them off to C++. So that my users do not have to manage two mechanisms to set random seeds, I've constructed a solution (shown

On 30/07/2020 4:30 p.m., Tommy Jones wrote: > Thank you for this. I'd like to be sure I understand the > intuition?correctly. Is the following true from what you said? > > I can just fix the seed at the C++ level and the results will still be > (pseudo) random because the initialization at the R level is (pseudo) > random. No, that's not quite right. Let me try

Thank you Duncan and Gabriel. I think that my trivial example was a little too trivial and is causing some confusion. What's happening in the real function I'm writing is... 1. In R: Draw tens-of-thousands of times from a handful to Gamma RVs with different parameters to initialize some variables. (Technically, I'm calling gtools::rdirichlet which calls stats::rgamma) 2. Transfer the