similar to: Interface for package supplied random number generator

Hi, Our department has detected a bug in the implementation of the Kinderman-Ramage generator for normal random variates in version 1.7.0, which can be seen from the below R session. (Consecutive calls for chisq.test(...) always gives p-values very close to 0.) We have already encountered this bug in version 1.6.2 The error is in file R-1.7.0/src/nmath/snorm.c Here is a patch for this file to

Hi, I am a little bit surprised by the following output of 'formals'. Is this the intended behavior? > f <- function(a=1,b=-1) { a+b } > class(formals(f)$a) [1] "numeric" > class(formals(f)$b) [1] "call" Josef -- ----------------------------------------------------------------------------- Josef Leydold | WU (Vienna University of Economics and

Dear maintainers of the parallel package, I ran into an issue with the parallel package in R-3.1.0. The following code prints the message "NULL!" quite a lot. library(parallel) for (n in 1:1000) { p <- mcparallel(sqrt(n)) res <- mccollect(p, wait=FALSE, timeout=1000) mccollect(p) if (is.null(res)) cat(n," NULL!\n") } It does not happen in

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

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

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

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

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

Before the next release we really should to sort out the bias issue in sample() reported by Ottoboni and Stark in https://www.stat.berkeley.edu/~stark/Preprints/r-random-issues.pdf and filed aa a bug report by Duncan Murdoch at https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17494. Here are two examples of bad behavior through current R-devel: set.seed(123) m <- (2/5) * 2^32

Hi, I sometimes play around with extreme parameters for distributions and found that qbeta is not always monotone as the following example shows. I don't know whether this is serious enough to submit a bug report (as this example is near to the limitations of floating point arithmetic). Josef > x <- qbeta((0:100)/100,0.01,5) > x [1] 0.000000e+00 1.253990e-201 1.589622e-171

Hello everyone. If I do f <- function(n){max(rnorm(n))} plot(sapply(rep(5000,4000),f)) #[this takes my PC about 30 seconds] then I get something quite unexpected: gaps in the distribution. For me, the most noticable one is at about 3.6. Do others get this? Is it an optical illusion? It can't be right, can it? Or maybe I just don't understand the good ol' Gaussian very

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

There seems to be a minor problem with reproducing numbers from rnorm with Box-Muller. The pattern suggests it might have something to do with the value that gets dropped when an odd number of numbers is requested. (Details below.) Also, could "user-supplied" be added as an option for normal.kind in RNGkind. I'm sure the Box-Muller in R is better than my own attempt, but I would

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

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)

?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

R 0.64 on windows NT 4.0 Sometimes I got an error message by doing this > .Random.seed <- c(1, 1:2) > .Random.seed [1] 1 1 2 > runif(5) Warning: Wrong length .Random.seed; forgot initial RNGkind? set to Wichmann-Hill[1] 0.02253721 0.84832584 ........ Sometimes I do not get error message: > .Random.seed <- c(1, 1:2) > .Random.seed [1] 1 1 2 > runif(1) [1] 0.5641106 >

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 >

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

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,