similar to: set.seed() in a package

We commit a similar sin in the help pages, e.g. example(set.seed) ; runif(2) example(set.seed) ; runif(2) gives you the same random uniforms both times. (Of course it isn't that much of an issue, since you would rarely be running examples before any serious simulations.) You can fairly easily work around that by saving and restoring .Random.seed. I wonder if that isn't also true of the

> 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

On 30/10/2019 9:08 a.m., peter dalgaard wrote: > We commit a similar sin in the help pages, e.g. > > example(set.seed) ; runif(2) > example(set.seed) ; runif(2) > > gives you the same random uniforms both times. (Of course it isn't that much of an issue, since you would rarely be running examples before any serious simulations.) I think it's pretty common in example

Forgot to say: For, oseed <- base::getRandomSeed() on.exit(base::setRandomSeed(oseed)) one could upgrade set.seed() to take this role, e.g. oseed <- set.seed(0xBEEF) on.exit(set.seed(oseed)) Current, set.seed() always return NULL. BTW, and my memory might be bad, I think I mentioned this in the past but was told that you cannot reset the RNG state for all types of RNG kinds.

On 30/10/2019 3:28 a.m., Marvin Wright wrote: > Hi all, > > I recently found several calls of set.seed() in a CRAN package. These calls are in a plot function, which could lead to unexpected behaviour. See https://github.com/sammo3182/interplot/issues/33 <https://github.com/sammo3182/interplot/issues/33> for a description of the problem. > > I checked the CRAN repository

I've got another edition of my simulation replication framework. I'm attaching 2 R files and pasting in the readme. I would especially like to know if I'm doing anything that breaks .Random.seed or other things that R's parallel uses in the environment. In case you don't want to wrestle with attachments, the same files are online in our SVN

Dear all, I was doing an experiment to disprove some theory therefore performing lot of random simulation. Goal is to show the audience that although something has very rare chance to occur but it doesn't mean that event would be impossible. In this case after getting that rare event I need to show that same scenario for multiple times to explain other audience. Hence I need to somehow

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

On 04/11/2017 10:20 PM, Daniel Nordlund wrote: > Tirthankar, > > "random number generators" do not produce random numbers. Any given > generator produces a fixed sequence of numbers that appear to meet > various tests of randomness. By picking a seed you enter that sequence > in a particular place and subsequent numbers in the sequence appear to > be unrelated.

I want to start R processes on multiple processors from single shell script and I want all of them to have different random seeds. One way of doing this is sleep 2 # (with 'sleep 1' I am often getting the same number) ... set.seed(unclass(Sys.time())) Is there a simpler way without a need to sleep between invoking different R processes ? Ryszard

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

There is no any mention about it neither in API nor in Guide. How to use these features? The only gist with two sentences is in db/seed.rb file. That''s really not enough. -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To unsubscribe from this group and stop receiving emails

I'm running into problems with set.seed--maybe I'm misunderstanding something. I'm running R 1.5.1 on Windows 2000. I'm basically trying to capture the random seed so that I can reproduce a simulation if it's necessary later. Using set.seed, I can certainly get reproducible results, but not the results I get on the first pass. Here's an example: # Generate a random

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

Hello, In ?set.seed I notice that a seed is created from the system time. Thus if two machines were (hypothetically) running for the same time and R was started simultaneously on both, the would have the same seeds (correct?). I assume reading from /dev/random would be different for both of these machines, so my question is why not use an integer read from /dev/random to create the seed? Would

Bill, Appreciate the point that both you and Serguei are making, but the sequence in question is not a selected or filtered set. These are values as observed in a sequence from a mechanism described below. The probabilities required to generate this exact sequence in the wild seem staggering to me. T On Fri, Nov 3, 2017 at 11:27 PM, William Dunlap <wdunlap at tibco.com> wrote: >

hello all, I use the R standalone math library in my own C program, and the default R random number generator can be seeded with set_seed(const unsigned int, const unsigned int). How could I seed the RNG with an instance of .Random.seed ? I would need this or a similar workaround for debugging purposes. More precisely, I use the default R random number generator to sample from various

I am using /set.seed()/ before the /sample/ function. How does the length of the argument of /set.seed()/ and order of the digits affect how the sampling is carried out? Specifically, I have used set.seed(123456789). Will this configuration give me a genuinely random sampling?? Thank you in anticipation. Penny. [[alternative HTML version deleted]]

Bill, I have clarified this on SO, and I will copy that clarification in here: "Sure, we tested them on other 8-digit numbers as well & we could not replicate. However, these are honest-to-goodness numbers generated by a non-adversarial system that has no conception of these numbers being used for anything other than a unique key for an entity -- these are not a specially constructed