[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.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@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[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 drive (happens to be mapped to L:/). It
has the following structure (as per
http://cran.r-project.org/doc/manuals/R-admin.html#Setting-up-a-package-repository):
L:/R/bin/windows/contrib/
2.11/
2.12/
2.13/
2.14/
2.15/
L:/R/src/contrib
I created a bare bones package (`anRpackage`) using `package.skeleton`. I
cleaned it up and added a basic function, checked it and built it from command
line using `R CMD INSTALL --build .`. That generates `anRpackage_1.0.zip` with
no errors. Note:
```
$ R CMD INSTALL --build --version
R add-on package installer: 2.15.2 (r61015)
```
I have Rtools 2.16 installed (as this is for R >2.15.1 to R 2.16.x). I have
also followed the instructions here:
http://cran.r-project.org/doc/manuals/R-admin.html#The-Windows-toolset
I copy that to L:/R/bin/windows/contrib/2.15 (for example), run
`tools::write_PACKAGES()` in that directory. That successfully generates the
packages file. I also run `tools::write_PACKAGES()` in L:/R/src/contrib to
generate an empty PACKAGES file.
I have the following in my .Rprofile (among other things):
```
.First <- function ()
{
options( repos = c(CRAN = "http://cran.csiro.au/";,
LREPO = "file:///L:/R/"))
}
```
I run `install.packages("anRpackage") and I get the following error:
```
Installing package(s) into ‘C:/Program Files/R/R-2.15.2/library’
(as ‘lib’ is unspecified)
Warning in install.packages : package ‘anRpackage’ is not available (for R
version 2.15.2)
```
Same issue on another Windows machine.
However, if I run
`install.packages("L:/R/bin/windows/contrib/2.15/anRpackage_1.0.zip",
repos=NULL)`, it installs successfully.
I do not have this problem in R 2.15.1.
NB: If I provide full file path to install.packages and set repos=NULL, and
then check the package's DESCRIPTION file in the help, I see this at the
bottom:
`Built: R 2.15.2; ; 2012-11-01 00:22:07 UTC; windows`
(when I've built package using 2.15.2 obviously)
Thanks.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
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 ever imagined it would become this big. The serious implications of repository and related policies for future development and health of this ecosystem and its community members deserve transparent debate. As with any movement based on volunteer contribution, R will adapt or be replaced. As far as I'm aware -- and welcome correction -- we don't have a list to discuss policies by CRAN or other actors. This list seems appropriate because it generally involves those doing development for R. Whether R-core should or should not listen to such deliberations is also open to debate. My own view -- which could change depending on how things evolve -- is that a small central committee is fine as long as they are able to both support and be supported by the wider development community that provides the packages giving R its strength. Unfortunately, I sense that the time demands of what is now a major software system are such that communications (and tempers) are getting frayed. I urge attention to this, and also to ideas of organizational behaviour and evolution, so we keep R healthy. Those who know me will realize I'm willing to put in time to act as the glue in building communications. I'm also a bit surprised nobody has mentioned the mirrors -- if the mirror repositories choose, say, the Alternative R Archive Network, which might also include sweater patterns, the effectiveness of the CRAN system would be crippled. John Nash __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
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 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@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
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 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, rip...@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, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
