ross at biostat.ucsf.edu
Wed May 20 04:56:30 CEST 2009
The R project wiki sounds like a great place. Thanks for the
On Tue, 2009-05-19 at 20:55 -0500, Dirk Eddelbuettel wrote:
> | P.S. My latest discovery is that set.seed is a no-op after you've
> | initialized rsprng's generator.
> Yes, wasn't that the point of (r)sprng ?
It did happen to be the behavior I was looking for. But R framework for
user random number generators provides hooks by which they can intercept
calls to set.seed (among other things).
Also, before I looked at the code I thought rsprng might be operating
completely outside of the usual R RNG framework, so that only explicit
calls to the rsprng interface would get sprng random numbers. It is
certainly more convenient for the replacement to be fairly pervasive.
It seems a bit of a problem to me that the current approach is a mix of
the two cases. On the one hand, rsprng could be a drop-in replacement
for R's random numbers, in which case set.seed would work, as would the
standard commands for getting and setting state of the stream.
Admittedly, the semantics of set.seed in a parallel RNG are murky; maybe
it should just throw an error.
On the other hand, it could be completely independent, accessible only
by its own specialized calls while the standard R RNG's proceeded
My attempt to use set.seed was based on a guess that this second model
(rsprng completely separate) was what was going on.
More information about the R-sig-hpc