similar to: Initialising Mersenne-Twister with one integer

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

On 08/30/2016 06:29 PM, 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

Whomever, I recently sent the "bug report" below toR-core at r-project.org and have just been asked to instead submit it to you. Although I am basically not an R user, I have installed version 3.3.1 and am also the author of a statistics program written in Visual Basic that contains a component which correctly implements the Mersenne Twister (MT) algorithm. I believe that it is

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

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 definitely introduces problems in reproducibility, so it's

I wonder how useful a (set of?) "time machine" functions which look up /infer things like this based on a date would be. Could ease the pain of changes generally, though not remove it completely. ~G On Wed, Aug 31, 2016 at 5:45 PM, Paul Gilbert <pgilbert902 at gmail.com> wrote: > > > On 08/30/2016 06:29 PM, Duncan Murdoch wrote: > >> I don't see evidence of

Dear R experts, we are preparing an R-package to compute the Oja Median which contains some C++ code in which random numbers are needed. To generate the random numbers we use the following Mersenne-Twister implementation: // MersenneTwister.h // Mersenne Twister random number generator -- a C++ class MTRand // Based on code by Makoto Matsumoto, Takuji Nishimura, and Shawn Cokus // Richard J.

How many distinct values can rnorm return? I assume that rnorm manipulates runif in some way, runif uses the Mersenne Twister, which has a period of 2^19937 - 1. Given that runif returns a 64 bit precision floating point number in [0,1], the actual period of the Mersenne Twister in a finite precision world must be significantly less. One of the arguments for Monte Carlo over the bootstrap is

Gabe As mentioned on Twitter, I think the following behavior should be fixed as part of the upcoming changes: R.version.string ## [1] "R Under development (unstable) (2019-02-25 r76160)" .Machine$double.digits ## [1] 53 set.seed(123) RNGkind() ## [1] "Mersenne-Twister" "Inversion"??????? "Rejection" length(table(runif(1e6))) ## [1] 999863 I don't

This is cross-posted from SO (https://stackoverflow.com/q/47079702/1414455), but I now feel that this needs someone from R-Devel to help understand why this is happening. We are facing a weird situation in our code when using R's [`runif`][1] and setting seed with `set.seed` with the `kind = NULL` option (which resolves, unless I am mistaken, to `kind = "default"`; the default being

>>>>> Tirthankar Chakravarty <tirthankar.lists at gmail.com> >>>>> on Fri, 3 Nov 2017 13:19:12 +0530 writes: > This is cross-posted from SO > (https://stackoverflow.com/q/47079702/1414455), but I now > feel that this needs someone from R-Devel to help > understand why this is happening. Why R-devel -- R-help would have been

Ralf I don't doubt this is expected with the current implementation, I doubt the implementation is desirable. Suggesting to turn this to pbirthday(1e6, classes = 2^53) ## [1] 5.550956e-05 (which is still non-zero, but much less likely to cause confusion.) Best regards Kirill On 26.02.19 10:18, Ralf Stubner wrote: > Kirill, > > I think some level of collision is actually

Full_Name: Wolfgang Huber Version: 1.8.0 OS: Linux Submission from: (NULL) (193.174.58.146) The man page for RNGkind says that the default is Mersenne-Twister, and when I start R interactively, I get in fact > RNGkind() [1] "Mersenne-Twister" "Inversion" However, during the execution of "R CMD check" I get > > ### ** Examples > > > > RNGkind()

The random numbers in a stream initialized with one seed should have about the desired distribution. You don't win by changing the seed all the time. Your seeds caused the first numbers of a bunch of streams to be about the same, but the second and subsequent entries in each stream do look uniformly distributed. You didn't say what your 'upstream process' was, but it is easy to

Dear all, Recently I am generating large random samples (10M) and any duplicated numbers are not desired. We tried several RNGs in R and found Wichmann-Hill did not produce duplications. The duplication problem is the interesting birthday problem. If there are M possible numbers, randomly draw N numbers from them, the average number of dupilcations D = N(N-1)/2/M. For Knuth-TAOCP and

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.

Dear List, Recently I got the comment that the implementation of the random number generator used by default in R (Mersenne-Twister) could not be "safe" for 64-bits machines, so I decided to put the question here because I do not have expertise in that topic, and because this question could be "too technical for R-help's audience". I apologise if this is not the case.

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

Another other generator is subject to the same problem with the same probabilitiy. > Filter(function(s){set.seed(s, kind="Knuth-TAOCP-2002");runif(1,17,26)>25.99}, 1:10000) [1] 280 415 826 1372 2224 2544 3270 3594 3809 4116 4236 5018 5692 7043 7212 7364 7747 9256 9491 9568 9886 Bill Dunlap TIBCO Software wdunlap tibco.com On Fri, Nov 3, 2017 at 10:31 AM, Tirthankar

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