similar to: A bug in the R Mersenne Twister (RNG) code?

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

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

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

?Random.user says (in svn trunk) Optionally, functions \code{user_unif_nseed} and \code{user_unif_seedloc} can be supplied which are called with no arguments and should return pointers to the number of seeds and to an integer array of seeds. Calls to \code{GetRNGstate} and \code{PutRNGstate} will then copy this array to and from \code{.Random.seed}. And it offers as an example void

Hi, It seems to me that the Mersenne-Twister PRNG can be initialised using one integer instead of 624 integers, since inside RNG.c code there's a function defined as MT_sgenrand(Int32). How do I actually set this seed within R? I've tried: > .Random.seed <- c(3, 1) > runif(1) Error in runif(1) : .Random.seed has wrong length In addition, is '3' actually the

Hi, I'm currently R porting SF Mersenne Twister algorithm of Matsumoto and Saito. To get the full power of their code, I want to use their fonction fill_array32 which need aligned memory. That is to say I need to use the C function memalign on windows, posix_memalign on linux and classic malloc on Mac OS. In 'writing R extenstion', they recommand to use R_alloc function to

Hi, I'm currently R porting SF Mersenne Twister algorithm of Matsumoto and Saito. To get the full power of their code, I want to use their fonction fill_array32 which need aligned memory. That is to say I need to use the C function memalign on windows, posix_memalign on linux and classic malloc on Mac OS. In 'writing R extenstion', they recommand to use R_alloc function to

Hi all, I have happened to work on MS .NET for sometime now, and I found that this language offers RNG what is called as Donald E. Knuth's subtractive random number generator algorithm (found here: http://msdn.microsoft.com/en-us/library/system.random.aspx#Y12). ? Here I was wondering whether R also have same RNG in it's inventory, so looked at ?set.seed. There I found 2 related RNGs

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.

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

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

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

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

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

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.

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

In the code below, you seem to be essentially using the random number generator to implement a hash function. This isn't a good idea. My impression is that pseudo-random number generation methods are generally evaluated by whether the sequence produced from any seed "appears" to be random. Informally, there may be some effort to make long sequences started with seeds 1, 2, 3, etc.

> On 5 Nov 2017, at 15:17 , Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > > 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

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