search for: kinderman

Unfortunately, RNGkind is buggy. It will not generate warnings except the full name "Buggy Kinderman-Ramage" is supplied for normal.kind. match.arg is supposed to be called before "==" comparison. ======================================== Shengqiao Li Research Associate The Department of Statistics PO Box 6330 West Virginia University Morgantown, WV 26506-6330

On Wed, 19 Sep 2018 at 13:43, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > > I think the analyses are correct, but I doubt if a change to the default > is likely to be accepted as it would make it more difficult to reproduce > older results. I'm a bit alarmed by the logic here. Unbiased sampling seems basic for a statistical language. As a consumer of R I'd

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

...erator, or modify results used for comparisons in the tests. Since package testing is usually for code checking rather than statistical results, not using the best available generator is not usually an issue. Most of my own package testing already specifies the generator, lots uses "buggy Kinderman-Ramage" because tests were set up a long time ago. I will have to change package setRNG which warns when the default generator changes. (This warning is intentional because I was bitten badly by a small change in the S generator circa 1990.) > If this goes into base R, what's the b...

...Surely if the old results depend on the biased algorithm, then they are > false results? > Balancing backward compatibility and correctness is a tough problem here. If this goes into base R, what's the best way to do it? What was the protocol for migrating away from the "buggy Kinderman-Ramage" generator, back in the day? (Version 1.7 was sometime between 2001 and 2004). I couldn't find the exact commit in the GitHub mirror: this is related ... https://github.com/wch/r-source/commit/7ad3044639fd1fe093c655e573fd1a67aa7f55f6#diff-dbcad570d4fb9b7005550ff630543b37 ==...

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

...ile I am getting old and forgetful I can remember exactly one such change where behaviour was changed, and (one of the) generators was altered---if memory serves in the earlier days of R 1.* days . [ Goes digging...] Yes, see `help(RNGkind)` which details that R 1.7.0 made a change when "Buggy Kinderman-Ramage" was added as the old value, and "Kinderman-Ramage" was repaired. There once was a similar fix in the very early days of the Mersenne-Twister which is why the GNU GSL has two variants with suffixes _1998 and _1998. So your issue seems like pilot error to me: don't attac...

...ce a simulation if it's necessary later. Using set.seed, I can certainly get reproducible results, but not the results I get on the first pass. Here's an example: # Generate a random number to initialize > runif(1) [1] 0.965875 > RNGkind() [1] "Marsaglia-Multicarry" "Kinderman-Ramage" > > # Save random seed > temp.seed <- .Random.seed > > # Proceed to generate random uniforms > runif(5) [1] 0.18734034 0.02723140 0.46396251 0.10602243 0.64362777 > > # try to reproduce this sequence > set.seed(temp.seed, "default") > runif(5)...

Testing models is great and would not be able to create anything without it, but I am finding testing the controllers and views is a pain. Rest based controllers don''t seem to change that much when compared to the auto-generated code that obviously works. As for views I fail to see why testing it with a mock model does anything. Nothing is ensuring that when changes are made to the

...it would be > worth considering a change. But changing the default RNG definitely > introduces problems in reproducibility, Well "problems in reproducibility" is a bit vague. Results would always be reproducible by specifying kind="Mersenne-Twister" or kind="Buggy Kinderman-Ramage" for older results, so there is no problem reproducing results. The only problem is that users expecting to reproduce results twenty years later will need to know what random generator they used. (BTW, they may also need to record information about the normal or other generator, as...

...tion). A related problem sometimes broke attaching a package that had methods for basic functions, such as names(), used in method selection. o Empty expressions as in return(x,) could generate subsequent segfaults: they are now errors. (PR#2880) o The Kinderman-Ramage Normal Random Generator had several problems leading to not-quite normally distributed variates (PR#2846). One problem was traced to an error in the original 1976 JASA paper! Thanks to Josef Leydold and his team for investigating this. The old generator has...

...tion). A related problem sometimes broke attaching a package that had methods for basic functions, such as names(), used in method selection. o Empty expressions as in return(x,) could generate subsequent segfaults: they are now errors. (PR#2880) o The Kinderman-Ramage Normal Random Generator had several problems leading to not-quite normally distributed variates (PR#2846). One problem was traced to an error in the original 1976 JASA paper! Thanks to Josef Leydold and his team for investigating this. The old generator has...

...aces assert_fb_redirect_to. 3) follow_facebook_redirect! Used like follow_redirect! in integration tests. Again, extracts the URL from a response containing fb:redirect and makes a call to facebook_post to that URL. Give these a roll and let me know if there are any issues. Thanks a lot to Ryan Kinderman for this patch and the descriptions above. Shane -- http://shanesbrain.net | http://crimsonjet.com | http://myfitbuddy.com

Recieving digests. > RNGkind(NULL) [1] "Marsaglia-Multicarry" "Kinderman-Ramage" I would appreciate it if anybody has any comments on the following. Please do not comment on the R functions themselves, since they merely mimic a (bivariate simplification of a) C routine called from S. In particular, I would like to know if anything is available with regard to the...

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

...ring a change. But changing the default RNG definitely >> introduces problems in reproducibility, >> > > Well "problems in reproducibility" is a bit vague. Results would always be > reproducible by specifying kind="Mersenne-Twister" or kind="Buggy > Kinderman-Ramage" for older results, so there is no problem reproducing > results. The only problem is that users expecting to reproduce results > twenty years later will need to know what random generator they used. (BTW, > they may also need to record information about the normal or other &gt...

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

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

...Emmanuel Paradis <paradis@isem.univ-montp2.fr> Date: Wed, 26 Dec 2001 13:03:31 +0100 * PR# 1664 * Subject: Bug in rnorm. From: Rolf Turner <rolf@math.unb.ca> Date: Thu, 13 Jun 2002 16:35:59 -0300 (ADT) --Strange interaction between "Marsaglia-Multicarry" generator and --"Kinderman-Ramage" --method for normal variates. Apparently, switching either of them will help. Directory: Add-ons * PR# 974 * Subject: Lattice: panel.superpose with ordered factor groups From: John Maindonald <john.maindonald@anu.edu.au> Date: Sat, 9 Jun 2001 11:08:51 +1000 (EST) --The warnin...

...Emmanuel Paradis <paradis@isem.univ-montp2.fr> Date: Wed, 26 Dec 2001 13:03:31 +0100 * PR# 1664 * Subject: Bug in rnorm. From: Rolf Turner <rolf@math.unb.ca> Date: Thu, 13 Jun 2002 16:35:59 -0300 (ADT) --Strange interaction between "Marsaglia-Multicarry" generator and --"Kinderman-Ramage" --method for normal variates. Apparently, switching either of them will help. Directory: Add-ons * PR# 974 * Subject: Lattice: panel.superpose with ordered factor groups From: John Maindonald <john.maindonald@anu.edu.au> Date: Sat, 9 Jun 2001 11:08:51 +1000 (EST) --The warnin...