An embedded and charset-unspecified text was scrubbed... Name: not available URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20121101/b425d0da/attachment.pl>
An idea: Extend mclapply's mc.set.seed with an initial seed value?
3 messages · Ivan Popivanov, Paul Gilbert, Brian Ripley
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 and over again (on simple single processor systems), for example, by reloading a session with the seed set. Paul
On 12-11-01 08:46 PM, Ivan Popivanov wrote:
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.seed. Does this make sense? If you wonder how I came up with the idea: I spent a couple of hours debugging "unstable" results from parallel tuning of svms, which was caused by the parallel execution. In my case I can simply do the set.seed in the FUN argument function, but that may not be always the case. Ivan [[alternative HTML version deleted]]
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
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 users inadvertently using the same seed over and over again (on simple single processor systems), for example, by reloading a session with the seed set.
But R already makes what I take to be the wish really easy: set.seed(123) mclapply(...) sets the same seed on each child. And the other option, mc.set.seed = TRUE, makes it easy to have reproducibly different seeds on each child. See ?parallel::mcparallel .
Paul On 12-11-01 08:46 PM, Ivan Popivanov wrote:
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.seed. Does this make sense? If you wonder how I came up with the idea: I spent a couple of hours debugging "unstable" results from parallel tuning of svms, which was caused by the parallel execution. In my case I can simply do the set.seed in the FUN argument function, but that may not be always the case. Ivan
Brian D. Ripley, ripley at stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595