Timeline for R: Problem with runif: generated number repeats (more often than expected) after less than 100 000 steps
Current License: CC BY-SA 4.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 11, 2020 at 20:51 | comment | added | Henry |
@CarlWitthoft rnorm is not exactly qnorm(runif) but it is very close using the default methods: try set.seed(2020); a=rnorm(5); set.seed(2020); b=qnorm(runif(10))[c(1,3,5,7,9)]; cbind(a,b) to see what I mean
|
|
| May 11, 2020 at 19:04 | comment | added | Carl Witthoft |
@Henry you sure you aren't just running into floating-point precision errors? In addition, the rnorm function is not as simple as your "normifier" there.
|
|
| May 11, 2020 at 15:45 | comment | added | Henry |
@SextusEmpiricus something slightly peculiar is going on with that alternative: see n=100; set.seed(123); x=runif(2*n); x=x[2*(1:n)-1]; set.seed(123); y=pnorm(rnorm(n)); summary(x-y) and the differences are tiny but typically bigger than $2^{-32}$
|
|
| May 11, 2020 at 8:40 | comment | added | Sextus Empiricus |
Is rnorm using 64bit variables? While that is an ingenious solution, it is a bit strange workaround. There should be a simple runif call doing the same. Maybe we should make runif able to do the same. (In the other answer it is mentioned that 'most algorithms do this' so maybe it should be stated more explicitly which algorithms do this).
|
|
| May 11, 2020 at 7:53 | history | edited | Henry | CC BY-SA 4.0 |
reducing the likelihood
|
| May 11, 2020 at 1:07 | history | answered | Henry | CC BY-SA 4.0 |