I would recommend against maintaining multiple global variables and would instead take an object-oriented approach. Probably should define a reference class representing a random number stream (think java.util.Random). Then define a reference class representing a collection of them, tracking which one is current. Instantiate the collection class and keep a reference to it inside your package namespace. You could then define a new API that expects a random stream object as an argument, using the active one as the default. Your wrappers would delegate to that API, relying on the default.
On Wed, Aug 6, 2014 at 11:10 AM, Paul Johnson <pauljoh...@gmail.com> wrote: > I'm writing to ask for a policy exception, or advice on how to make > this package CRAN allowable. > > http://rweb.quant.ku.edu/kran/src/contrib/portableParallelSeeds_0.9.tar.gz > > Yesterday I tried to submit a package on CRAN and Dr Ripley pointed > out that I had not understood the instructions about packages. Here's > the part where the R check gives a Note > > * checking R code for possible problems ... NOTE > Found the following assignments to the global environment: > File âportableParallelSeeds/R/initPortableStreams.Râ: > assign("currentStream", n, envir = .GlobalEnv) > assign("currentStates", curStates, envir = .GlobalEnv) > assign("currentStream", 1L, envir = .GlobalEnv) > assign("startStates", runSeeds, envir = .GlobalEnv) > assign("currentStates", runSeeds, envir = .GlobalEnv) > assign("currentStream", as.integer(currentStream), envir = .GlobalEnv) > assign("startStates", runSeeds, envir = .GlobalEnv) > assign("currentStates", runSeeds, envir = .GlobalEnv) > > Altering the user's environment requires a special arrangement with > CRAN. I believe this is justified, I'll sketch the reasons now. But, > mostly, I'm at your mercy and if there is any way to make this > possible, I would be very grateful. > > To control & replace random number streams, it really is necessary to > alter the workspace. That's where the random generator state is > stored. It is acknowledged in Robert Gentleman' s Book, R Programming > for Bionformatics "The decision to have these [random generator] > functions manipulate a global variable, .Random.seed, is slightly > unfortunate as it makes it somewhat more difficult to manage several > different random number streams simultaneouslyâ (Gentleman, 2009, p. > 201). > > I have developed an understandable set of wrapper functions that handle > this. > > Some of you may recall this project. I've asked about it here a couple > of times. We allow separate streams of randoms for different purposes > within a single R run. There is a framework to save 1000s of those > sets in a file, so it can be used on a cluster or in a single > workstation. This is handy because, when 1 run in 10,000 on the > cluster exhibits some weird behavior, we can easily re-initiate that > interactively and see what's going on. > > I have a vignette "pps" that explains. I dropped a copy of that here > in case you don't want to get the package: > > http://pj.freefaculty.org/scraps/pps.pdf > > While working on that, I gained a considerably deeper understanding of > random generators and seeds. That is what this vignette is about > > http://pj.freefaculty.org/scraps/PRNG-basics.pdf > > > We've been running simulations on our cluster with the > portableParallelSeeds framework for 2 years, we've never had any > trouble. We are able to re-start runs, verify random number draws in > separate streams. > > PJ > -- > Paul E. Johnson > Professor, Political Science Assoc. Director > 1541 Lilac Lane, Room 504 Center for Research Methods > University of Kansas University of Kansas > http://pj.freefaculty.org http://quant.ku.edu > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]]
______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
