Re: [Rd] require( foo (= 2.1) )
On Sun, May 30, 2010 at 5:50 PM, Romain Francois rom...@r-enthusiasts.com wrote: Hi, Sure. I could and I would provide a patch. Since this is more of a nice to have, I wanted to first find out whether others would find it useful, and also if such a patch would have chances to get accepted by one of R-core members. Sometimes patches I or others provide upfront are not accepted. I'm not complaining about it, it is always an opportunity to learn something ... For starters you could write a function called requireVersion that does what you want. That would help you (since you say you often find yourself using this paradigm) and also it would help anyone else who does this. And since it wouldn't be a patch to R it wouldn't need R-gods to approve it. It would also make you think about how you'd parameterise the call - I wouldn't want to build something that had to parse foo (=2.1), for example, but having a minimum.version argument makes more sense. Shouldn't be that difficult, you've written most of it already! It might then get included in one of the packages of miscellany on CRAN, and then maybe become core R functionality (if you sacrifice the required animal to the R-gods, of course). Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] require( foo (= 2.1) )
Le 31/05/10 10:41, Barry Rowlingson a écrit : On Sun, May 30, 2010 at 5:50 PM, Romain Francois rom...@r-enthusiasts.com wrote: Hi, Sure. I could and I would provide a patch. Since this is more of a nice to have, I wanted to first find out whether others would find it useful, and also if such a patch would have chances to get accepted by one of R-core members. Sometimes patches I or others provide upfront are not accepted. I'm not complaining about it, it is always an opportunity to learn something ... For starters you could write a function called requireVersion that does what you want. That would help you (since you say you often find yourself using this paradigm) and also it would help anyone else who does this. And since it wouldn't be a patch to R it wouldn't need R-gods to approve it. It would also make you think about how you'd parameterise the call - I wouldn't want to build something that had to parse foo (=2.1) The code already exists, to process DESCRIPTION files with: Depends: foo (= 2.1) but I think I also prefer using another argument anyway. Then there is also : what do you do if a lower version is found: warning, error, something that is parameterized y another argument, ... for example, but having a minimum.version argument makes more sense. Shouldn't be that difficult, you've written most of it already! It might then get included in one of the packages of miscellany on CRAN, and then maybe become core R functionality (if you sacrifice the required animal to the R-gods, of course). Barry The problem with another function on top of require or library is that it either has to copy a lot of code from library or first call library and then find out if the loaded version is high enough. I think it is better that the package is not loaded at all if the version is not good enough (it might load the packages it depends on for nothing, etc ...) which is why I think a patch to library makes more sense. But, library or require currently don't have a ... sink so code like : require( foo, min.version = 2.1 ) would only work in, say R 2.12.0. Romain -- Romain Francois Professional R Enthusiast +33(0) 6 28 91 30 30 http://romainfrancois.blog.free.fr |- http://bit.ly/99bz5D : highlight 0.1-9 |- http://bit.ly/9CQ66r : RMetrics 2010 `- http://bit.ly/bklUXt : RcppArmadillo 0.2.1 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] require( foo (= 2.1) )
On Mon, May 31, 2010 at 10:41 AM, Barry Rowlingson b.rowling...@lancaster.ac.uk wrote: On Sun, May 30, 2010 at 5:50 PM, Romain Francois rom...@r-enthusiasts.com wrote: Hi, Sure. I could and I would provide a patch. Since this is more of a nice to have, I wanted to first find out whether others would find it useful, and also if such a patch would have chances to get accepted by one of R-core members. Sometimes patches I or others provide upfront are not accepted. I'm not complaining about it, it is always an opportunity to learn something ... For starters you could write a function called requireVersion that does what you want. That would help you (since you say you often find yourself using this paradigm) and also it would help anyone else who does this. And since it wouldn't be a patch to R it wouldn't need R-gods to approve it. It would also make you think about how you'd parameterise the call - I wouldn't want to build something that had to parse foo (=2.1), for example, but having a minimum.version argument makes more sense. Shouldn't be that difficult, you've written most of it already! I agree that this would be a useful extension to have. Exact setup of arguments can be discussed. I agree that only having foo (= 2.1) is not good (though probably the most flexible one). It might be that one want to specify a range of versions to load. Also, consider the case where are three libraries on the .libPaths() each having a different version of foo installed (this can happen in shared setups), e.g. libA/ containing foo v2.0 libB/ containing foo v2.1 libC/ containing foo v2.2 and .libPaths() contains libA, libB and libC in that order. What should happen with: (a) require(foo) - should it load v2.0, v2.1 or v2.2? Today the first one on the search path, i.e. v2.0. (b) require(foo (= 2.1)) - should it throw an error saying it found v2.0 but it is not sufficient, or should it skip v2.0 and load v2.1 or v2.2? (c) require(foo (= 2.1)) - should it load v2.0 or v2.1? If require() is smart and skips insufficient versions, that is, does not just load the first available one, then one also have to worry about consistency to other functions such as packageDescription(). /Henrik It might then get included in one of the packages of miscellany on CRAN, and then maybe become core R functionality (if you sacrifice the required animal to the R-gods, of course). Barry __ 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] Documentation of biplot for princomp
Hi,
I think that the documentation for the biplot function `biplot.princomp' is
inconsistent with what it actually does. Here is what the documentation
states:
pc.biplot
If true, use what Gabriel (1971) refers to as a principal component
biplot, with lambda = 1 and observations scaled up by sqrt(n) and variables
scaled down by sqrt(n). Then inner products between variables approximate
covariances and distances between observations approximate Mahalanobis
distance.
Here is what the code looks like:
getAnywhere(biplot.princomp)
A single object matching 'biplot.princomp' was found
It was found in the following places
registered S3 method for biplot from namespace stats
namespace:stats
with value
function (x, choices = 1L:2L, scale = 1, pc.biplot = FALSE, ...)
{
if (length(choices) != 2)
stop(length of choices must be 2)
if (!length(scores - x$scores))
stop(gettextf(object '%s' has no scores, deparse(substitute(x))),
domain = NA)
lam - x$sdev[choices]
if (is.null(n - x$n.obs))
n - 1
lam - lam * sqrt(n)
if (scale 0 || scale 1)
warning('scale' is outside [0, 1])
if (scale != 0)
lam - lam^scale
else lam - 1
if (pc.biplot)
lam - lam/sqrt(n)
biplot.default(t(t(scores[, choices])/lam), t(t(x$loadings[,
choices]) * lam), ...)
invisible()
}
1. Let us consider the default options: scale = 1 and pc.biplot =
FALSE. Now, lam = x$sdev * sqrt(n). Hence, the observations (scores) are
scaled down by eigenvalue * sqrt(n) and variables (loadings) are scaled up
by eigenvalue * sqrt(n).
2. Now consider: scale = 1 and pc.biplot = TRUE. We have, lam =
x$sdev . The observations are scaled down by eigenvalue and variables are
scaled up by eigenvalue.
Thus, in either case the documentation does not seem to be consistent with
the implementation. Am I missing something here?
Thanks Best,
Ravi.
--
Ravi Varadhan, Ph.D.
Assistant Professor,
Center on Aging and Health,
Johns Hopkins University School of Medicine
(410)502-2619
rvarad...@jhmi.edu
http://www.jhsph.edu/agingandhealth/People/Faculty_personal_pages/Varadhan.h
tml
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Suggested tidying up
Package grDevices has a function cm() to convert from inches to centimeters. Its definition is: cm - function(x) 2.54*x As far as I can tell, the function is not used anywhere in the R sources (I grepped for cm(, cm) and , cm.) I did not check for all packages on CRAN, though. May I propose to remove this apparently useless function from the sources? [I stubbled upon this function because my package actuar also has a cm() function that masks the one from grDevices.] Dr. Vincent Goulet Full Professor École d'actuariat, Université Laval, Québec vincent.gou...@act.ulaval.ca http://vgoulet.act.ulaval.ca __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
