search for: seeding

Hi all, I have a pretty basic question about categorical variables but I can't seem to be able to find answer so I am hoping someone here can help. I found that if the factor names are all in numbers, fitting the model in lm would return labels that are not very recognizable. # Example: let's just assume that we want to fit this model fit <- lm(height ~ age + Seed,

Hello again, I was testing today's SNAP (openssh-SNAP-20000830.tar.gz) in my Solaris 2.6-8 environment, when I found some problems with the ssh2 support. While connecting, it seeds the RNG something like 32 times! And then once connected, it seeds again 2 or 3 times with *every* keystroke! This makes for some slow going. This happens on all of the Solaris boxes I tried. Binary was

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,

Could someone please suggest a method to store the current random seed. I'm having trouble understanding how to correctly use set.seed and .Random.seed. Specifically, I have the following code that crashes: set.seed(seed) for(i in 1:10){ print( runif(1)) } To get around this I need to split the number of iterations into chunks: set.seed(seed) for(i in 1:5){ print(runif(1))

I have noticed that when I iterate permutations of short vectors with the same seed, the cycle lengths are much shorter than I would expect by chance. For example: X <- 1:10 Xorig <- X start <- 112358 N <- 10 for (i in 1:N) { seed <- start + i for (j in 1:1000) { # Maximum cycle length to consider set.seed(seed) # Re-seed RNG to same initial state X <- sample(X)

Dear expeRts, I struggle with the following problem using snow clusters for parallel computing: I would like to specify l'Ecuyer's random number generator. Base R creates a .Random.seed of length 7, the first value indicating the kind fo random number generator. I would thus like to use the components 2 to 7 as the seed for l'Ecuyer's random number generator. By doing so, I

I am writing a function for the purposes of a simulation. Due to memory problems, the function sometimes crashes. In order to get around this problem, I would like to include to be able to save the "last" seed, so I can pick up with the next run of the simulation after a "crash". I am having trouble understanding what is going on with .Random.seed! For each run of the

Two compatibility issues found while trying to convert a simulation from S to R. 1. set.seed() We don't have this function. According to Venables & Ripley it just picks a seed from a list of 1000 possibilities. How about "set.seed" <-function (i) { if (any(i > 1000) | any(i < 1)) stop("argument to set.seed() must be in 1:1000")

Hi, this is related to a question just raised on Bioconductor where one function sets the random seed internally but never resets it, which results in enforced down streams random samples being deterministic. What is the best way to reset the random seed when you use set.seed() within a function? Is it still to re-assign '.Random.seed' in the global environment as following example

Hello, happy new year. I've come back to a problem from last spring. I need to understand what what is the technically correct method to save a seed and then re-set it. Although this example arises in the context of MT19937, I'm needing to do this with other generators as well, including L'Ecuyer streams. The puzzle is this comment in ?Random: "?set.seed? is the recommended way

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

is there a way to avoid c() appending ".0" and ".1" to seed? --8<---------------cut here---------------start------------->8--- > c("nons"=1, "seed"=3) nons seed ## good! 1 3 > c("nons"=1, "seed"=tab[1]) nons seed.0 ## don't want ".0"! 1 2344600 >

Hi, I would like to construct a transition matrix from a data frame with annual transitions of marked plants. plant<-c(1:6) class<-c("seed","seed", "seed", "veg", "rep", "rep") fate<-c("dead", "veg","veg","rep", "rep", "veg") trans<-data.frame(plant, class, fate)

Hi Boris, Do a search on "the order of elements of the symmetric group". (This search will also turn up homework questions and solutions.) You will understand why you are seeing this once you understand how a permutation is decomposed into cycles and how the order relates to a partition of n (n=10 in your case). Enjoy! Eric On Fri, Dec 8, 2017 at 6:39 AM, Boris Steipe <boris.steipe

> On 30/10/2019 9:08 a.m., peter dalgaard wrote: > > You can fairly easily work around that by saving and restoring .Random.seed. This is actually quite tedious to get correct; it requires you to under how and when .Random.seed is set, and what are valid values on .Random.seed. For instance, a common mistake (me too) is to reset to .GlobalEnv$.Random.seed <- NULL in a fresh R

Hi. Suppose I have a function which does some random number generation within. The random number generation inside the function changes the value of .Random.seed in the calling environment. If I want to restore the pre-function call .Random.seed, I can do: save.seed<-.Random.seed result<-myfunction() .Random.seed<-save.seed Is there a way to do the restoration inside the function?

For reasons that are best known to myself [ ;-) ] I have a value of .Random.seed saved (via dput()) in a file ``.Random.seed.save''. In my .Rprofile I have the lines: .Random.seed <- dget(".Random.seed.save") Junk <- dget(".Random.seed.save") print(all.equal(.Random.seed,dget(".Random.seed.save")))

Martin, Thanks for the helpful reply. Alas I had forgotten that (implied) unfavorable comparisons of *nix systems with Windows systems would likely draw irate (but always substantive) responses on the R-devel list -- poor phrasing on my part. :) Regardless, let me try to address some of the concerns related to the construction of the MRE itself and try to see if we can clean away the shrubbery

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

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