2018-04-18 22:49 GMT+02:00 Gertjan van den Burg <gertjanvandenb...@gmail.com>: > Thanks for your comment. Your suggestion wouldn't solve my original problem > unfortunately, because then I'd have to reverse engineer R's RNG for my > Python package. Besides, the quality of the random numbers doesn't really > matter here, it only matters that they're the same across my packages.
You could instead write a vignette instructing the user on how to replace the default RNG with your SyncRNG. Wouldn't this solve the problem? Iñaki > > Gertjan > > On 04/18/2018 08:00 PM, Dirk Eddelbuettel wrote: >> >> On 18 April 2018 at 11:36, Gertjan van den Burg wrote: >> | While waiting to get this message posted to the list, I've solved the >> | problem by copying the stdlib rand() and srand() functions into my >> | package under a different name. This makes the check pass and ensures my >> | RNG does not interfere with R's RNG. >> >> I recommend against that. The check, while dated, is valid because many >> (old) >> implementations of rand and srand were of (now known) poor quality. >> >> You have R, you should use its RNGs. Your users may expect that. Accessing >> eg >> runif is easy and documented, and we can trust the RNG behind it. >> >> Dirk >> > > ______________________________________________ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
