[Rd] An idea: Extend mclapply's mc.set.seed with an initial seed value?

Hello, Have been thinking that sometimes users may want each process to initialize its random seed with a specific value rather then the current seed. This could be keyed off depending whether mc.set.seed is logical, preserving the current behaviour, or numerical, using the value in a call to set.

[Rd] Can't install.packages() from local repo in 2.15.2

Hi guys I think there's a high chance this is a bug. But I can't rule out that I can be blamed for this. I've posted this to bugzilla (#15092). Then I read that I probably should have posted it to R-develop first. Sorry for doing this in the wrong order. I've set up a local repo on my local

Re: [Rd] if(!CRAN()){...} / Repository policies

If CRAN were a passive repository, the discussion about its policies would not be relevant to this list e.g., SourceForge. However, the development of R and its packages are very intimately connected to the CRAN repository policy. I doubt any of the players in building our current R ecosystem

Re: [Rd] An idea: Extend mclapply's mc.set.seed with an initial seed value?

I appreciate your problem, and getting reproducible random generator results on a parallel system is something to be careful about. However, I would avoid making it too easy to have a fixed seed. In earlier days there were mistakes too often made by users inadvertently using the same seed over

Re: [Rd] An idea: Extend mclapply's mc.set.seed with an initial seed value?

On Fri, 2 Nov 2012, Paul Gilbert wrote: I appreciate your problem, and getting reproducible random generator results on a parallel system is something to be careful about. However, I would avoid making it too easy to have a fixed seed. In earlier days there were mistakes too often made by user