Re: [Rd] na.omit option in prcomp: formula interface only
Dear r-devel list, dear Ben I came across a post of Ben Bolker from Feb 2012 (see below) on handling NA values in prcomp(). As I faced the same issue and found Ben's suggestions interesting, I was wondering whether this led to further discussions I might have missed? I understand handling NA values is far from trivial, but would it be possible to add a warning in the documentation, and/or whenever na.action is used with prcomp() on a data frame (suggesting to use the formula instead?)? Thanks! Matthieu Stigler This is a wishlist/request for discussion about the behaviour of the na.action option in prcomp, specifically the fact that it only applies to the formula interface. I had a question from a friend (who is smart and careful and generally R's TFM, although like all of us he misses things sometimes) asking why the na.action= argument didn't seem to be doing anything in prcomp (i.e. one gets an "Error in svd(x, nu=0): infinite or missing values in 'x'"). Some poking later, I realized that na.action only applied to the formula interface (so I told him to try prcomp(~.,data=x,...) instead). Sufficiently careful reading of the help page, with hindsight, revealed that na.action only appears in the arguments for the formula method, not the default (on the other hand, 'scale.' only appears in the default formula, but it *does* work with prcomp.formula as well, because prcomp.formula passes ... through to prcomp.default ...) Would it be reasonable to (at least) add a sentence to the documentation saying that na.action applies only to the formula interface or (possibly) to add some NA-processing machinery to prcomp.default to allow it to handle na.action as well? (I can appreciate from looking at stats:::prcomp.formula that the NA-processing is not completely trivial ...) Ben Bolker [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] maintaining multiple R versions
Aaron For the problem I had in mind, changing a couple of environment variables does not seem like more work than this, but it may solve a bigger problem than the one I was thinking about. If I understand correctly, you can use this to switch among versions of R, similar to what I am doing and still with versions in different directories found by a PATH setting. But, in addition, it is also possible that the R versions were compiled with different gcc and other tools, as long as those are still installed on the system. Does it also work if you upgrade the OS and have newer versions of system libraries, etc, or do you then need to recompile the R versions? Thanks, Paul On 13-01-18 02:58 PM, Aaron A. King wrote: Have you looked at Environment Modules (http://modules.sourceforge.net/)? I use it to maintain multiple versions of R. Users can choose their default and switch among them at the command line. Aaron On Fri, Jan 18, 2013 at 02:04:13PM -0500, Paul Gilbert wrote: (somewhat related to thread [Rd] R CMD check not reading R_LIBS ) For many years I have maintained R versions by building R (./configure ; make) in a directory indicating the version number, putting the directory/bin on my path, and setting R_LIBS_SITE. It seems only one version can easily be installing in /usr/bin, and in any case that requires root, so I do not do that. There may be an advantage to installing somewhere in a directory with the version number, but that does not remove the need to set my path. (If there is an advantage to installing I would appreciate someone explaining briefly what it is.) My main question is whether there is a better ways to maintaining multiple versions, in some way that lets users choose which one they are using? (The only problem I am aware of with my current way of doing this is: if the system has some R in /usr/bin then I have to set my preferred version first, which means shell commands like "man" find R's pager first, and do not work.) Thanks, Paul __ 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
[Rd] Arguments passing through dot-dot-dot lose ability to check for missing()?
Hi R-devel. Is the following behavior in g1() and h1() expected? It seems
to make "..." arguments work slightly differently from named arguments.
#missing() has the property that it looks "up the chain"
#for example, "z" can be missing in f3 even if
#that argument did have a name ("y") in f2
f1 <- function(x, ...) {
cat("In f1, missing(x) is ", missing(x), "\n")
f2(x, ...)
}
f2 <- function(y, ...) {
cat("In f2, missing(y) is ", missing(y), "\n")
f3(y, ...)
}
f3 <- function(z, ...) {
cat("in f3, missing(z) is ", missing(z), "\n")
}
f1( , 2) #all TRUE
#does this also work with ... arguments? It seems to lose track.
g1 <- function(...) {
cat("In g1, missing(..1) is ", missing(..1), "\n")
g2(...)
}
g2 <- function(...) {
cat("In g2, missing(..1) is ", missing(..1), "\n")
g3(...)
}
g3 <- function(...) {
cat("in g3, missing(..1) is ", missing(..1), "\n")
}
g1( , 2) #TRUE, TRUE, FALSE ?!
# we can also elicit this lossiness without looking at the virtual ..n
# symbols:
h1 <- function(x, ...) {
cat("in h1, missing(x) is ", missing(x), "\n")
h2(x, ...)
}
hh1 <- function(...)
h2(...)
h2 <- function(...)
h3(...)
h3 <- function(z, ...)
cat("in h3, missing(z) is ", missing(z), "\n")
h3( , 1) #missing in h3
h2( , 1) #missing in h3
h1( , 1) #missing in h1 but NOT h3
hh1( , 1) #also not missing in h3
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
