similar to: bias issue in sample() (PR 17494)

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

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

Luke, I'm happy to help with this. Its great to see this get tackled (I've cc'ed Kelli Ottoboni who helped flag this issue). I can prepare a patch for the RNGkind related stuff and the doc update. As for ???, what are your (and others') thoughts about the possibility of a) a reproducibility API which takes either an R version (or maybe alternatively a date) and sets the RNGkind

Kirill, I think some level of collision is actually expected! R uses a 32bit MT that can produce 2^32 different doubles. The probability for a collision within a million draws is > pbirthday(1e6, classes = 2^32) [1] 1 Greetings Ralf On 26.02.19 07:06, Kirill M?ller wrote: > Gabe > > > As mentioned on Twitter, I think the following behavior should be fixed > as part of the

I'm getting ready to submit an update of survival, and is my habit I run the checks on all packages that depend/import/suggest? survival.? I am getting some very odd behaviour wrt non-reproducability.? It came to a head when some things failed on one machine and worked on another.?? I found that the difference was that the failure was using the 3/27 release and the success was still on a

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

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

I sent this to R-devel early last month, but have received no response, so I guess it really is a bug. This looks like a bug to me, and is a bit hard to describe, but easy to reproduce. ? Basically, if RNGkind is saved as something other than the default, and if the first operation in a session is a set.seed(), the default is reverted to. ?Reproduce by: cafe-rozo> ?R --vanilla R version

Dear list, For the implementation of a particular optimization algorithm it is very important the random number generator. I would like to know if somebody could tell me what is the random number generator used by default in the 'runif' function. >From the help page of 'runif' and '.Random.seed' I guess that the default algorithm is 'Mersenne-Twister', but I

Dear R-Aficionados: I realize that no random number generator is perfect, so what I report below may be a result of that simple fact. However, if I have made an error in my thinking I would greatly appreciate being corrected. I wish to illustrate the behavior of small samples (n=10) and so generate 100,000 of them. n.samples <- 1000000 sample.size = 10 p <- 0.0001 z.normal <- qnorm(p)

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

This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-851401618-1218751024=:15885 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE I didn't describe the problem clearly. It's about the number of distinct=20 values. So just

Dear list, I have noticed surprisingly big performance differences of runif() between Windows XP and (Debian) linux on similar CPUs (Pentium D 3.0GHz (WinXP)/3.2GHz (Linux)) and I wonder if there is a simple explanation for the difference. On a linux system (with a slightly better CPU and 1GB more RAM), execution of runif() seems to consume about 80% more CPU time than on a Windows XP

I am wondering whether there is a bug in rnorm. When generating rnorm(1000000) and counting the cases > 4 and the cases < (-4) I get rather unexpectedly low counts for the latter. The problem goes away when using qnorm(runif(1000000)). Fritz Scholz, PhD Applied Statistics Group Boeing Phantom Works fritz.scholz at pss.boeing.com 425-865-3623 Tu/We 206-542-6545 (most likely)

On Mon, Feb 26, 2018 at 3:25 PM, Gary Black <gwblack001 at sbcglobal.net> wrote: (Sorry to be a bit slow responding.) You have not supplied a complete example, which would be good in this case because what you are suggesting could be a serious bug in R or a package. Serious journals require reproducibility these days. For example, JSS is very clear on this point. To your question >

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

It doesn't seem too hard to come up with plausible ways in which this could give bad results. Suppose I sample rows from a large dataset, maybe for bootstrapping. Suppose the rows are non-randomly ordered, e.g. odd rows are males, even rows are females. Oops! Very non-representative sample, bootstrap p values are garbage. David On Wed, 19 Sep 2018 at 21:20, Duncan Murdoch <murdoch.duncan

Hi, subject more or less says it all. I freely admit to not having bothered to find some of the online papers about method of testing the quality of random number generators -- but in an idle moment I wondered what to expect from something like the following: randa<-runif(1000) randb<-runif(1000) t.test(randa,randb)$p.value var.test(randa,randb)$p.value [repeat ad nauseum] Is the

Today I struggled for hours to understand some unexpected package test results. It turned out that this is because package "parallel", buried deep in my dependencies, calls runif() during it's initialization and in this way changes the random number sequence. This seems to be a part of a more general question--which kind of functions can we trust if we want to preserve random

?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