[Rd] On Section 2.5:Sub-architectures in the R Installation and Administration manual
Dear all,
there are a few issues regarding Section 2.5: Sub-architectures in the
R Installation and Administration manual (referring to Version 2.6.2)
that I would like to raise:
1.) The manual states:
@code{R CMD INSTALL} will detect if more that one build is installed
and try to install packages with the appropriate library objects
for each. This will not be done if the package has an executable
@code{configure} script or a @file{src/Makefile} file. In such
cases you can install for extra builds by
@example
R [EMAIL PROTECTED] CMD INSTALL --libs-only @var{pkg}(s)
@end example
My experience with the --libs-only flag is that if the installation of
the package fails, then the package is removed. Is this really desired
behaviour? If yes, then the manual should perhaps warn that this might
happen. However, in my opinion, this behaviour is undesirable. As I
understand it, `--libs-only' would only be used if the package was
already successfully installed for (at least) one sub-architecture.
Why should the failure to install it for another sub-architecture
remove the complete package, including the successful build for another
sub-architecture.
2.) On my machines (running Kubuntu Linux (gutsy)), I usually install a
32 bit version, by specifying r_arch=32 to the configure line, and a 64
version, by specifying r_arch=64 to the configure line. This seems to
be in line with the following recommendation in the manual:
If you want to mix sub-architectures compiled on different
platforms (for example @cputype{x86_64} Linux and @cputype{i686}
Linux), it is wise to use explicit names for each, and you may
also need to set @option{libdir} to ensure that they
install into the same place.
However, after installing R 2.6.2 in such manner, trying to start R
resulted in the following error message:
Error: R executable not found
As far as I can tell, this is due to the code that was added at the
beginning of the bash script R (to support parallel 32/64-bit
installations using multilib on Linux?) which tries to locate the R
executable but does not search deep enough into the directory structure
if multiple architectures are installed using the r_arch option to the
configure line (for both/all architectures).
3) The manual also states in that section:
On Linux, there is an alternative mechanism for mixing 32-bit and
64-bit libraries known as @emph{multilib}. If a Linux distribution
supports multilib, then parallel builds of @R{} may be installed in
the sub-directories @file{lib} (32-bit) and @file{lib64} (64-bit).
[...]
As far as I can tell, Kubuntu Linux distributions support multilib.
However on these distributions /lib64 and /usr/lib64 are links to /lib
and /usr/lib, respectively, where the 64-bit libraries reside and the
32-bit libraries reside in /lib32 and /usr/lib32. Thus, the above
paragraph is somewhat confusing to somebody who is running a Kubuntu
Linux distribution. (Presumably the same holds for Debian and all
other distributions derived from Debian.)
Cheers,
Berwin
=== Full address =
Berwin A TurlachTel.: +65 6515 4416 (secr)
Dept of Statistics and Applied Probability+65 6515 6650 (self)
Faculty of Science FAX : +65 6872 3919
National University of Singapore
6 Science Drive 2, Blk S16, Level 7 e-mail: [EMAIL PROTECTED]
Singapore 117546http://www.stat.nus.edu.sg/~statba
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 0.45<0.45 = TRUE (PR#10744)
hadley wickham: > It's more than that as though, as floating point addition is no longer > guaranteed to be commutative or associative, and multiplication does > not distribute over addition. Many concepts that are clear cut in > pure math become fuzzy in floating point math - equality, singularity > of matrices etc etc. Even simple averages may be complicated: eps=1 while(1-eps != 1) eps=eps/2 eps=eps*2 (1-1*eps+1-2*eps+1-3*eps)/3 == 1-1:3*eps# TRUE FALSE FALSE mean(1-1:3*eps) == 1-1:3*eps# FALSE TRUE FALSE sum(1-1:3*eps)/3 == 1-1:3*eps # FALSE FALSE TRUE ((1-1*eps)+(1-2*eps)+(1-3*eps))/3 == 1-1:3*eps # FALSE FALSE TRUE so sometimes all the values may lie on the same side of the "average". [Win R 2.6.1] Heikki Kaskelma Munkkiniemi, Finland __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Uninstall registry key the same for all versions (PR#10746)
Hi Duncan,
>> I just wanna add a related suggestion that when you have multiple
>> installations and you run "Unistall R 2.6.0" the first dialog
>> ('R for Windows Uninstall') you see says "Are you sure you want to
>> completely remove R for Windows and all of its components?" This
>> message does not specify the version being uninstalled, so without
>> previous experience you certainly wonder if this is going to install
>> all of your R installations or just one.
>
> I'm just testing now, but I suspect Gerhard's suggestion of
> specifying AppID will fix this too.
Thanks for looking into this. I think setting "AppName" to the same
as "AppVerName" (which includes the version number) should cover both
Henrik's and my suggestion.
Regards
Gerhard
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Uninstall registry key the same for all versions (PR#10746)
On 2/13/2008 3:27 AM, Gerhard Thallinger wrote:
> Hi Duncan,
>
>>> I just wanna add a related suggestion that when you have multiple
>>> installations and you run "Unistall R 2.6.0" the first dialog
>>> ('R for Windows Uninstall') you see says "Are you sure you want to
>>> completely remove R for Windows and all of its components?" This
>>> message does not specify the version being uninstalled, so without
>>> previous experience you certainly wonder if this is going to install
>>> all of your R installations or just one.
>>
>> I'm just testing now, but I suspect Gerhard's suggestion of
>> specifying AppID will fix this too.
>
> Thanks for looking into this. I think setting "AppName" to the same
> as "AppVerName" (which includes the version number) should cover both
> Henrik's and my suggestion.
Yes, that looks like the easiest solution. The Inno Setup docs tell you
not to do that; I'm just trying it now to see if it produces really ugly
messages somewhere.
An alternative solution is to override the ConfirmUninstall message, but
that has to be done separately in all the languages we support, so I
like the AppVerName solution better.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 0.45<0.45 = TRUE (PR#10744)
On Wed, 13 Feb 2008, Heikki Kaskelma wrote: > hadley wickham: >> It's more than that as though, as floating point addition is no longer >> guaranteed to be commutative or associative, and multiplication does >> not distribute over addition. Many concepts that are clear cut in >> pure math become fuzzy in floating point math - equality, singularity >> of matrices etc etc. > > Even simple averages may be complicated: > > eps=1 > while(1-eps != 1) eps=eps/2 > eps=eps*2 Such calculations are dangerous: we provide .Machine to avoid the need for them. (They have plagued various LAPACK implementations, for example.) Most R implementations these days use higher-precision registers for intermediate internal calculations such as those in mean() and sum(). > (1-1*eps+1-2*eps+1-3*eps)/3 == 1-1:3*eps# TRUE FALSE FALSE Which is not an average, and the difference from the last line below just illustrates Hadley's point. > mean(1-1:3*eps) == 1-1:3*eps# FALSE TRUE FALSE > sum(1-1:3*eps)/3 == 1-1:3*eps # FALSE FALSE TRUE > ((1-1*eps)+(1-2*eps)+(1-3*eps))/3 == 1-1:3*eps # FALSE FALSE TRUE > > so sometimes all the values may lie on the same side of the "average". Only if you DIY average! Note that mean() does a better job than you managed, because it uses a higher-precision accumulator. I think the moral is to rely on the work of those to whom this is not at all 'complicated' (you should check out some of the rest of the R internals to see 'complicated'). > [Win R 2.6.1] > > > Heikki Kaskelma > Munkkiniemi, Finland > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, [EMAIL PROTECTED] 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
[Rd] Perils of R_LIBRARY_PATH
The R front end sets (via etc/ldpath) R_LIBRARY_PATH, including
R_JAVA_LD_LIBRARY_PATH. Perhaps the later is too obliging, as I've just
be caught by it in a way that took me a while to track down.
One of my machines has a Sun jdk1.6.0* JDK installed, and as a result
we have
${R_JAVA_LD_LIBRARY_PATH=${JAVA_HOME}/lib/amd64/server:${JAVA_HOME}/lib/amd64:
${JAVA_HOME}/../lib/amd64}
What I was not aware of was that the Sun JDK contains Gtk+ libraries such
as cairo and pango, and those were older than the ones whose headers I
had compiled against which eventually resulted in a crash.
It seems to be an issue only for a JDK: perhaps Simon can tweak his
incantations to use only the JRE library path (and avoid the
'../lib/amd64' above)?
--
Brian D. Ripley, [EMAIL PROTECTED]
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
Re: [Rd] assigning NULLs to elements of a list
:) Well, yes, but what do you do with a named vector if you want to remove an element by name? It is not general: you cannot do that on vectors, matrices, arrays and all inherited objects anyway. Using a negative index is a standard and throughout practice of deleting elements in R. Surely one can have exceptions or extended behaviour for different classes, like list and data.frame here, but I cannot say it is really necessary to have it in order to produce a clean, easily readable and reliable code. Yes, I know now, this NULL assignment has existed there for long time and I am not about to propose its removal, but I really do not see a good reason for having it either. I would never use it in my code either. After all you do not assign NULLs to elements of a non-list vector or matrix or array. Best, Oleg Gabor Grothendieck wrote: > But what about by name? > > a <- list(a = 1, b = 2, c = 3) > > a$b <- NULL > > > On Feb 13, 2008 9:39 AM, Oleg Sklyar <[EMAIL PROTECTED]> wrote: >> Hmm, I think the pretty traditional R style does the job... >> >> a = list(1,2,3) >> a[-2] >> >> So I really do not see a good reason for doing a[2] = NULL instead of a >> = a[-2] >> >> >> Jeffrey J. Hallman wrote: >>> >From your tone, I gather you don't much like this behavior, and I can see >>> >your >>> point, as it not very intuitive that setting a list element to NULL deletes >>> any existing element at that index. But is there a better way to delete an >>> element from a list? Maybe there should be. >>> >>> Jeff >>> >>> Prof Brian Ripley <[EMAIL PROTECTED]> writes: > I have just came across an (unexpected to me) behaviour of lists when > assigning NULLs to list elements. I understand that a NULL is a valid R > object, thus assigning a NULL to a list element should yield exactly the > same result as assigning any other object. So I was surprised when > assigning a NULL in fact removed the element from the list. Is this an > intended behaviour? If so, does anybody know where is it documented and > what is a good way around? Yes, it was apparently intended: R has long done this. x <- list(a=c(1L,2L), b=matrix(runif(4),2,2), c=LETTERS[1:3]) x[2] <- list(NULL) is what I think you are intending. See e.g. the comment in subassign.c /* If "val" is NULL, this is an element deletion */ /* if there is a match to "nlist" otherwise "x" */ /* is unchanged. The attributes need adjustment. */ >> -- >> Dr Oleg Sklyar * EBI-EMBL, Cambridge CB10 1SD, UK * +44-1223-494466 >> >> __ >> >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> -- Dr Oleg Sklyar * EBI-EMBL, Cambridge CB10 1SD, UK * +44-1223-494466 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] assigning NULLs to elements of a list
But what about by name? a <- list(a = 1, b = 2, c = 3) a$b <- NULL On Feb 13, 2008 9:39 AM, Oleg Sklyar <[EMAIL PROTECTED]> wrote: > Hmm, I think the pretty traditional R style does the job... > > a = list(1,2,3) > a[-2] > > So I really do not see a good reason for doing a[2] = NULL instead of a > = a[-2] > > > Jeffrey J. Hallman wrote: > >>From your tone, I gather you don't much like this behavior, and I can see > >>your > > point, as it not very intuitive that setting a list element to NULL deletes > > any existing element at that index. But is there a better way to delete an > > element from a list? Maybe there should be. > > > > Jeff > > > > Prof Brian Ripley <[EMAIL PROTECTED]> writes: > >>> I have just came across an (unexpected to me) behaviour of lists when > >>> assigning NULLs to list elements. I understand that a NULL is a valid R > >>> object, thus assigning a NULL to a list element should yield exactly the > >>> same result as assigning any other object. So I was surprised when > >>> assigning a NULL in fact removed the element from the list. Is this an > >>> intended behaviour? If so, does anybody know where is it documented and > >>> what is a good way around? > >> Yes, it was apparently intended: R has long done this. > >> > >> x <- list(a=c(1L,2L), b=matrix(runif(4),2,2), c=LETTERS[1:3]) > >> x[2] <- list(NULL) > >> > >> is what I think you are intending. > >> > >> See e.g. the comment in subassign.c > >> > >> /* If "val" is NULL, this is an element deletion */ > >> /* if there is a match to "nlist" otherwise "x" */ > >> /* is unchanged. The attributes need adjustment. */ > > > > -- > Dr Oleg Sklyar * EBI-EMBL, Cambridge CB10 1SD, UK * +44-1223-494466 > > __ > > 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] 0.45<0.45 = TRUE (PR#10744)
hadley wickham wrote: > It's more than that as though, as floating point addition is no longer > guaranteed to be commutative or associative, and multiplication does > not distribute over addition. Many concepts that are clear cut in > pure math become fuzzy in floating point math - equality, singularity > of matrices etc etc. I've just noticed that R doesn't calculate e^pi - pi as equal to 20: > exp(pi)-pi == 20 [1] FALSE See: http://www.xkcd.com/217/ Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Surprising behaviour of levelplot in lattice package
Hi Deepayan,
levelplot from the lattice package produces a peculiar output when
called on a matrix whose column or row names contained duplicated
elements. In particular, the plot contains white stripes, and the
arrangement of data regions and axes labels seems messed up. I did not
see this documented (my apologies if this is an oversight) and guess
that it is unintended:
library("lattice")
m = matrix(runif(12L), ncol=3L)
colnames(m) = c("A", "A", "B")
rownames(m) = c("x", "y", "y", "z")
print(levelplot(m))
Best wishes
Wolfgang
--
Wolfgang Huber EBI/EMBL Cambridge UK http://www.ebi.ac.uk/huber
> sessionInfo()
R version 2.7.0 Under development (unstable) (2008-02-13 r44450)
x86_64-unknown-linux-gnu
locale:
LC_CTYPE=it_IT.UTF-8;LC_NUMERIC=C;LC_TIME=it_IT.UTF-8;LC_COLLATE=it_IT.UTF-8;LC_MONETARY=it_IT.UTF-8;LC_MESSAGES=it_IT.UTF-8;LC_PAPER=it_IT.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=it_IT.UTF-8;LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] lattice_0.17-4 fortunes_1.3-4
loaded via a namespace (and not attached):
[1] grid_2.7.0
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 0.45<0.45 = TRUE (PR#10744)
On 13-Feb-08 12:40:48, Barry Rowlingson wrote: > hadley wickham wrote: > >> It's more than that as though, as floating point addition is >> no longer guaranteed to be commutative or associative, and >> multiplication does not distribute over addition. Many concepts >> that are clear cut in pure math become fuzzy in floating point >> math - equality, singularity of matrices etc etc. > > I've just noticed that R doesn't calculate e^pi - pi as equal to 20: > > > exp(pi)-pi == 20 > [1] FALSE > > See: http://www.xkcd.com/217/ > > Barry Barry, These things fluctuate. Once upon a time (sometime in 1915 will do) you could get $[US]4.81 for £1.00 sterling. One of the rare brief periods when the folks on opposite side of the Atlantic saw i^i (to within .Machine$double.eps, which at the time was about 0.001, if you were lucky and didn't make a slip of the pen). R still gets it approximately right: 1/(1i^1i) [1] 4.810477+0i $i^i = £1 Best wishes, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 13-Feb-08 Time: 15:57:02 -- XFMail -- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] assigning NULLs to elements of a list
Hmm, I think the pretty traditional R style does the job... a = list(1,2,3) a[-2] So I really do not see a good reason for doing a[2] = NULL instead of a = a[-2] Jeffrey J. Hallman wrote: >>From your tone, I gather you don't much like this behavior, and I can see your > point, as it not very intuitive that setting a list element to NULL deletes > any existing element at that index. But is there a better way to delete an > element from a list? Maybe there should be. > > Jeff > > Prof Brian Ripley <[EMAIL PROTECTED]> writes: >>> I have just came across an (unexpected to me) behaviour of lists when >>> assigning NULLs to list elements. I understand that a NULL is a valid R >>> object, thus assigning a NULL to a list element should yield exactly the >>> same result as assigning any other object. So I was surprised when >>> assigning a NULL in fact removed the element from the list. Is this an >>> intended behaviour? If so, does anybody know where is it documented and >>> what is a good way around? >> Yes, it was apparently intended: R has long done this. >> >> x <- list(a=c(1L,2L), b=matrix(runif(4),2,2), c=LETTERS[1:3]) >> x[2] <- list(NULL) >> >> is what I think you are intending. >> >> See e.g. the comment in subassign.c >> >> /* If "val" is NULL, this is an element deletion */ >> /* if there is a match to "nlist" otherwise "x" */ >> /* is unchanged. The attributes need adjustment. */ > -- Dr Oleg Sklyar * EBI-EMBL, Cambridge CB10 1SD, UK * +44-1223-494466 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Best way to reset random seed when using set.seed() in a function?
Hi,
this is related to a question just raised on Bioconductor where one
function sets the random seed internally but never resets it, which
results in enforced down streams random samples being deterministic.
What is the best way to reset the random seed when you use set.seed()
within a function? Is it still to re-assign '.Random.seed' in the
global environment as following example illustrates? I'm not too kind
of having function modifying the global environment, if not really
necessary.
foo <- function(n) {
# Pop random seed
if (!exists(".Random.seed", mode="numeric"))
sample(NA);
oldSeed <- .Random.seed;
# Fixed seed to get reproducible samples here
set.seed(0xbeef);
x <- sample(5);
# Proof of concept: 'x' should be the same all the time
stopifnot(identical( x, as.integer(c(4,2,5,1,3)) ));
# Push random seed to old state
assign(".Random.seed", oldSeed, envir=globalenv())
# Continue as nothing happened
sample(n);
}
> foo(5)
[1] 4 2 3 5 1
> foo(5)
[1] 4 2 3 1 5
> foo(5)
[1] 5 3 1 4 2
> foo(5)
[1] 5 3 2 4 1
> foo(5)
Is this the way to do it?
Thanks
Henrik
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Best way to reset random seed when using set.seed() in a function?
On Wed, 13 Feb 2008, Henrik Bengtsson wrote:
> Hi,
>
> this is related to a question just raised on Bioconductor where one
> function sets the random seed internally but never resets it, which
> results in enforced down streams random samples being deterministic.
>
> What is the best way to reset the random seed when you use set.seed()
> within a function? Is it still to re-assign '.Random.seed' in the
> global environment as following example illustrates? I'm not too kind
> of having function modifying the global environment, if not really
> necessary.
It is necessary. Of course, any use of random numbers modifies this
variable in the global environment, so many, many functions already do.
There is a write-up in 'R Internals' of what is permissible in
modifying the base and global environments.
> foo <- function(n) {
> # Pop random seed
> if (!exists(".Random.seed", mode="numeric"))
>sample(NA);
> oldSeed <- .Random.seed;
>
> # Fixed seed to get reproducible samples here
> set.seed(0xbeef);
> x <- sample(5);
>
> # Proof of concept: 'x' should be the same all the time
> stopifnot(identical( x, as.integer(c(4,2,5,1,3)) ));
>
> # Push random seed to old state
> assign(".Random.seed", oldSeed, envir=globalenv())
>
> # Continue as nothing happened
> sample(n);
> }
>
>> foo(5)
> [1] 4 2 3 5 1
>> foo(5)
> [1] 4 2 3 1 5
>> foo(5)
> [1] 5 3 1 4 2
>> foo(5)
> [1] 5 3 2 4 1
>> foo(5)
>
> Is this the way to do it?
>
> Thanks
>
> Henrik
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Brian D. Ripley, [EMAIL PROTECTED]
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
Re: [Rd] Best way to reset random seed when using set.seed() in a function?
When is this really necessary? I have seen functions that do this, I
have never seen any usage where I think it is necessary. Usually it
is because the functions do say mcmc or cross-validation and wants
repeatable behaviour. But if the user really wants that, he/she can
just do it outside the functions. On the other hand, if functions
play with the random generator they are in peril or destroying a
possible outer loop which also uses random numbers.
Kasper
On Feb 13, 2008, at 8:57 AM, Henrik Bengtsson wrote:
> Hi,
>
> this is related to a question just raised on Bioconductor where one
> function sets the random seed internally but never resets it, which
> results in enforced down streams random samples being deterministic.
>
> What is the best way to reset the random seed when you use set.seed()
> within a function? Is it still to re-assign '.Random.seed' in the
> global environment as following example illustrates? I'm not too kind
> of having function modifying the global environment, if not really
> necessary.
>
> foo <- function(n) {
> # Pop random seed
> if (!exists(".Random.seed", mode="numeric"))
> sample(NA);
> oldSeed <- .Random.seed;
>
> # Fixed seed to get reproducible samples here
> set.seed(0xbeef);
> x <- sample(5);
>
> # Proof of concept: 'x' should be the same all the time
> stopifnot(identical( x, as.integer(c(4,2,5,1,3)) ));
>
> # Push random seed to old state
> assign(".Random.seed", oldSeed, envir=globalenv())
>
> # Continue as nothing happened
> sample(n);
> }
>
>> foo(5)
> [1] 4 2 3 5 1
>> foo(5)
> [1] 4 2 3 1 5
>> foo(5)
> [1] 5 3 1 4 2
>> foo(5)
> [1] 5 3 2 4 1
>> foo(5)
>
> Is this the way to do it?
>
> Thanks
>
> Henrik
>
> __
> 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] removing last piece of grid graphical output with grid.remove
Hello -
If I create multiple pieces of output in grid, and use grid.remove() to
try to remove the output from the graphics device, I cannot seem to
remove the final piece of output from the device until I 'refresh' the
graphics device by giving it focus. The function grid.remove() does
appear to remove the grob from the display list, however.
I noticed this when the example on page 200-201 in Paul Murrell's R
Graphics book did not work as expected when using
grid.remove("circles"). Can anyone replicate this?
## Example
library(grid)
## Create two circles
grid.circle(name = "redcircle", r = .20, gp = gpar(col = "red"))
grid.circle(name = "bluecircle", r = .25, gp = gpar(col = "blue"))
## removes the blue circle
grid.remove("bluecircle")
## the red circle will be deleted from the grid display list, but
## the graphics device will still show it until I 'refresh' the
## device by giving it focus via mouse or alt+tab, or producing
## more grid output
grid.remove("redcircle") ## still on my X11 device!
## more grid output
grid.text("Now the circle is gone!", name = "txt")
## But I can't get rid of this text on the device
## until I refresh device or do another grid call
grid.remove("txt") ## still on my X1 device!
> sessionInfo()
R version 2.6.2 (2008-02-08)
i686-pc-linux-gnu
locale:
LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=en_US.UTF-8;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C
attached base packages:
[1] grid stats graphics grDevices utils datasets methods
[8] base
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Best way to reset random seed when using set.seed() in a function?
On Feb 13, 2008 9:32 AM, Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
> On Wed, 13 Feb 2008, Henrik Bengtsson wrote:
>
> > Hi,
> >
> > this is related to a question just raised on Bioconductor where one
> > function sets the random seed internally but never resets it, which
> > results in enforced down streams random samples being deterministic.
> >
> > What is the best way to reset the random seed when you use set.seed()
> > within a function? Is it still to re-assign '.Random.seed' in the
> > global environment as following example illustrates? I'm not too kind
> > of having function modifying the global environment, if not really
> > necessary.
>
> It is necessary. Of course, any use of random numbers modifies this
> variable in the global environment, so many, many functions already do.
>
> There is a write-up in 'R Internals' of what is permissible in
> modifying the base and global environments.
Thank you, and thanks for the pointer. I had another question if
'.Random.seed' can end up somewhere else than in the global
environment, but 'R Internals' clearly states that .Random.seed
belongs in the global environment. My short example was not explicit
about that (and hence to bullet proof). Here is an update version:
foo <- function(n) {
# Store old random state
if (!exists(".Random.seed", mode="numeric", envir=globalenv()))
sample(NA);
oldSeed <- get(".Random.seed", mode="numeric", envir=globalenv());
# Fixed seed to get reproducible samples here
set.seed(0xbeef);
x <- sample(5);
# Proof of concept: 'x' should be the same all the time
stopifnot(identical( x, as.integer(c(4,2,5,1,3)) ));
# Reset random seed to old state
assign(".Random.seed", oldSeed, envir=globalenv());
# Continue as nothing happened
sample(n);
}
Cheers
Henrik
>
>
> > foo <- function(n) {
> > # Pop random seed
> > if (!exists(".Random.seed", mode="numeric"))
> >sample(NA);
> > oldSeed <- .Random.seed;
> >
> > # Fixed seed to get reproducible samples here
> > set.seed(0xbeef);
> > x <- sample(5);
> >
> > # Proof of concept: 'x' should be the same all the time
> > stopifnot(identical( x, as.integer(c(4,2,5,1,3)) ));
> >
> > # Push random seed to old state
> > assign(".Random.seed", oldSeed, envir=globalenv())
> >
> > # Continue as nothing happened
> > sample(n);
> > }
> >
> >> foo(5)
> > [1] 4 2 3 5 1
> >> foo(5)
> > [1] 4 2 3 1 5
> >> foo(5)
> > [1] 5 3 1 4 2
> >> foo(5)
> > [1] 5 3 2 4 1
> >> foo(5)
> >
> > Is this the way to do it?
> >
> > Thanks
> >
> > Henrik
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> --
> Brian D. Ripley, [EMAIL PROTECTED]
> 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
Re: [Rd] Best way to reset random seed when using set.seed() in a function?
I think in general it is a good idea to use on.exit() to reset the
seed if you mess with it. Otherwise you can generate unintended
consequences for other programs. Something like:
old.seed <- setRNG(kind = "default", seed = test.seed, normal.kind =
"default")
on.exit(setRNG(old.seed))
(BTW, setRNG is a simple little utility in the setRNG package, to help
set and save some of the other things you need besides the seed, if you
are going to try to reproduce results.)
Paul
Henrik Bengtsson wrote:
> Hi,
>
> this is related to a question just raised on Bioconductor where one
> function sets the random seed internally but never resets it, which
> results in enforced down streams random samples being deterministic.
>
> What is the best way to reset the random seed when you use set.seed()
> within a function? Is it still to re-assign '.Random.seed' in the
> global environment as following example illustrates? I'm not too kind
> of having function modifying the global environment, if not really
> necessary.
>
> foo <- function(n) {
> # Pop random seed
> if (!exists(".Random.seed", mode="numeric"))
> sample(NA);
> oldSeed <- .Random.seed;
>
> # Fixed seed to get reproducible samples here
> set.seed(0xbeef);
> x <- sample(5);
>
> # Proof of concept: 'x' should be the same all the time
> stopifnot(identical( x, as.integer(c(4,2,5,1,3)) ));
>
> # Push random seed to old state
> assign(".Random.seed", oldSeed, envir=globalenv())
>
> # Continue as nothing happened
> sample(n);
> }
>
>
>> foo(5)
>>
> [1] 4 2 3 5 1
>
>> foo(5)
>>
> [1] 4 2 3 1 5
>
>> foo(5)
>>
> [1] 5 3 1 4 2
>
>> foo(5)
>>
> [1] 5 3 2 4 1
>
>> foo(5)
>>
>
> Is this the way to do it?
>
> Thanks
>
> Henrik
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
La version française suit le texte anglais.
This email may contain privileged and/or confidential in...{{dropped:26}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Best way to reset random seed when using set.seed() in a function?
On Feb 13, 2008 11:07 AM, Paul Gilbert <[EMAIL PROTECTED]> wrote:
> I think in general it is a good idea to use on.exit() to reset the
> seed if you mess with it. Otherwise you can generate unintended
> consequences for other programs. Something like:
> old.seed <- setRNG(kind = "default", seed = test.seed, normal.kind =
> "default")
> on.exit(setRNG(old.seed))
Yes, agree; on.exit() should always be used when you want to cleanup
after yourself. Much better.
>
> (BTW, setRNG is a simple little utility in the setRNG package, to help
> set and save some of the other things you need besides the seed, if you
> are going to try to reproduce results.)
Thanks for this note. This seems much more natural to work with than
'.Random.seed'.
/Henrik
>
> Paul
>
>
> Henrik Bengtsson wrote:
> > Hi,
> >
> > this is related to a question just raised on Bioconductor where one
> > function sets the random seed internally but never resets it, which
> > results in enforced down streams random samples being deterministic.
> >
> > What is the best way to reset the random seed when you use set.seed()
> > within a function? Is it still to re-assign '.Random.seed' in the
> > global environment as following example illustrates? I'm not too kind
> > of having function modifying the global environment, if not really
> > necessary.
> >
> > foo <- function(n) {
> > # Pop random seed
> > if (!exists(".Random.seed", mode="numeric"))
> > sample(NA);
> > oldSeed <- .Random.seed;
> >
> > # Fixed seed to get reproducible samples here
> > set.seed(0xbeef);
> > x <- sample(5);
> >
> > # Proof of concept: 'x' should be the same all the time
> > stopifnot(identical( x, as.integer(c(4,2,5,1,3)) ));
> >
> > # Push random seed to old state
> > assign(".Random.seed", oldSeed, envir=globalenv())
> >
> > # Continue as nothing happened
> > sample(n);
> > }
> >
> >
> >> foo(5)
> >>
> > [1] 4 2 3 5 1
> >
> >> foo(5)
> >>
> > [1] 4 2 3 1 5
> >
> >> foo(5)
> >>
> > [1] 5 3 1 4 2
> >
> >> foo(5)
> >>
> > [1] 5 3 2 4 1
> >
> >> foo(5)
> >>
> >
> > Is this the way to do it?
> >
> > Thanks
> >
> > Henrik
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
>
> La version française suit le texte anglais.
>
>
>
> This email may contain privileged and/or confidential information, and the
> Bank of
> Canada does not waive any related rights. Any distribution, use, or copying
> of this
> email or the information it contains by other than the intended recipient is
> unauthorized. If you received this email in error please delete it
> immediately from
> your system and notify the sender promptly by email that you have done so.
>
>
>
> Le présent courriel peut contenir de l'information privilégiée ou
> confidentielle.
> La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute
> diffusion,
> utilisation ou copie de ce courriel ou des renseignements qu'il contient par
> une
> personne autre que le ou les destinataires désignés est interdite. Si vous
> recevez
> ce courriel par erreur, veuillez le supprimer immédiatement et envoyer sans
> délai à
> l'expéditeur un message électronique pour l'aviser que vous avez éliminé de
> votre
> ordinateur toute copie du courriel reçu.
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Surprising behaviour of levelplot in lattice package
On 2/13/08, Deepayan Sarkar <[EMAIL PROTECTED]> wrote: > On 2/13/08, Wolfgang Huber <[EMAIL PROTECTED]> wrote: > > Hi Deepayan, > > > > levelplot from the lattice package produces a peculiar output when > > called on a matrix whose column or row names contained duplicated > > elements. In particular, the plot contains white stripes, and the > > arrangement of data regions and axes labels seems messed up. I did not > > see this documented (my apologies if this is an oversight) and guess > > that it is unintended: > > Yes, the current design does not anticipate the possibility of > duplicated row and column names. A fix may or may not be simple; I > will look into it. Actually, the fix should be easy. A workaround is levelplot(m, ylim = colnames(m), xlim = rownames(m)) -Deepayan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Surprising behaviour of levelplot in lattice package
On 2/13/08, Wolfgang Huber <[EMAIL PROTECTED]> wrote:
> Hi Deepayan,
>
> levelplot from the lattice package produces a peculiar output when
> called on a matrix whose column or row names contained duplicated
> elements. In particular, the plot contains white stripes, and the
> arrangement of data regions and axes labels seems messed up. I did not
> see this documented (my apologies if this is an oversight) and guess
> that it is unintended:
Yes, the current design does not anticipate the possibility of
duplicated row and column names. A fix may or may not be simple; I
will look into it.
-Deepayan
>
>
> library("lattice")
> m = matrix(runif(12L), ncol=3L)
> colnames(m) = c("A", "A", "B")
> rownames(m) = c("x", "y", "y", "z")
> print(levelplot(m))
>
>
>
> Best wishes
> Wolfgang
>
> --
> Wolfgang Huber EBI/EMBL Cambridge UK http://www.ebi.ac.uk/huber
>
>
>
> > sessionInfo()
> R version 2.7.0 Under development (unstable) (2008-02-13 r44450)
> x86_64-unknown-linux-gnu
>
> locale:
> LC_CTYPE=it_IT.UTF-8;LC_NUMERIC=C;LC_TIME=it_IT.UTF-8;LC_COLLATE=it_IT.UTF-8;LC_MONETARY=it_IT.UTF-8;LC_MESSAGES=it_IT.UTF-8;LC_PAPER=it_IT.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=it_IT.UTF-8;LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
> other attached packages:
> [1] lattice_0.17-4 fortunes_1.3-4
>
> loaded via a namespace (and not attached):
> [1] grid_2.7.0
> >
>
> __
> 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] removing last piece of grid graphical output with grid.remove
Hi
Erik Iverson wrote:
> Hello -
>
> If I create multiple pieces of output in grid, and use grid.remove() to
> try to remove the output from the graphics device, I cannot seem to
> remove the final piece of output from the device until I 'refresh' the
> graphics device by giving it focus. The function grid.remove() does
> appear to remove the grob from the display list, however.
>
> I noticed this when the example on page 200-201 in Paul Murrell's R
> Graphics book did not work as expected when using
> grid.remove("circles"). Can anyone replicate this?
I've seen this type of behaviour on X11 before, but I think it is
specific to that device (e.g., you get the "right" behaviour on Windows).
I have not yet attempted to seek out the source of the X11 problem.
Paul
> ## Example
> library(grid)
>
> ## Create two circles
> grid.circle(name = "redcircle", r = .20, gp = gpar(col = "red"))
> grid.circle(name = "bluecircle", r = .25, gp = gpar(col = "blue"))
>
> ## removes the blue circle
> grid.remove("bluecircle")
>
> ## the red circle will be deleted from the grid display list, but
> ## the graphics device will still show it until I 'refresh' the
> ## device by giving it focus via mouse or alt+tab, or producing
> ## more grid output
> grid.remove("redcircle") ## still on my X11 device!
>
> ## more grid output
> grid.text("Now the circle is gone!", name = "txt")
>
> ## But I can't get rid of this text on the device
> ## until I refresh device or do another grid call
> grid.remove("txt") ## still on my X1 device!
>
>
> > sessionInfo()
> R version 2.6.2 (2008-02-08)
> i686-pc-linux-gnu
>
> locale:
> LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=en_US.UTF-8;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C
>
> attached base packages:
> [1] grid stats graphics grDevices utils datasets methods
> [8] base
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
[EMAIL PROTECTED]
http://www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Perils of R_LIBRARY_PATH
> Prof Brian Ripley writes:
> The R front end sets (via etc/ldpath) R_LIBRARY_PATH, including
> R_JAVA_LD_LIBRARY_PATH. Perhaps the later is too obliging, as I've just
> be caught by it in a way that took me a while to track down.
> One of my machines has a Sun jdk1.6.0* JDK installed, and as a result
> we have
> ${R_JAVA_LD_LIBRARY_PATH=${JAVA_HOME}/lib/amd64/server:${JAVA_HOME}/lib/amd64:
> ${JAVA_HOME}/../lib/amd64}
> What I was not aware of was that the Sun JDK contains Gtk+ libraries such
> as cairo and pango, and those were older than the ones whose headers I
> had compiled against which eventually resulted in a crash.
> It seems to be an issue only for a JDK: perhaps Simon can tweak his
> incantations to use only the JRE library path (and avoid the
> '../lib/amd64' above)?
Along with doing this, can we perhaps change JAVA_HOME to something like
R_JAVA_HOME? Apparently some applications require JAVA_HOME to be set
which in turn overrides the configured values for R ...
Best
-k
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] removing last piece of grid graphical output with grid.remove
On Thu, 14 Feb 2008, Paul Murrell wrote:
> Hi
>
>
> Erik Iverson wrote:
>> Hello -
>>
>> If I create multiple pieces of output in grid, and use grid.remove() to
>> try to remove the output from the graphics device, I cannot seem to
>> remove the final piece of output from the device until I 'refresh' the
>> graphics device by giving it focus. The function grid.remove() does
>> appear to remove the grob from the display list, however.
>>
>> I noticed this when the example on page 200-201 in Paul Murrell's R
>> Graphics book did not work as expected when using
>> grid.remove("circles"). Can anyone replicate this?
>
>
> I've seen this type of behaviour on X11 before, but I think it is
> specific to that device (e.g., you get the "right" behaviour on Windows).
>
> I have not yet attempted to seek out the source of the X11 problem.
The source is the behaviour of grid.newpage. I think you are expecting it
to clear the plot, but it doesn't (although a subsequent refresh will).
Here's a simpler example
library(grid)
grid.circle(name = "redcircle", r = .20, gp = gpar(col = "red"))
grid.newpage()
or in old money
plot(1:10)
plot.new()
As I suggested to Paul privately, it is a missing XSync call (and in fact
the second one I have found today). Will be fixed in R-patched shortly.
>
> Paul
>
>
>> ## Example
>> library(grid)
>>
>> ## Create two circles
>> grid.circle(name = "redcircle", r = .20, gp = gpar(col = "red"))
>> grid.circle(name = "bluecircle", r = .25, gp = gpar(col = "blue"))
>>
>> ## removes the blue circle
>> grid.remove("bluecircle")
>>
>> ## the red circle will be deleted from the grid display list, but
>> ## the graphics device will still show it until I 'refresh' the
>> ## device by giving it focus via mouse or alt+tab, or producing
>> ## more grid output
>> grid.remove("redcircle") ## still on my X11 device!
>>
>> ## more grid output
>> grid.text("Now the circle is gone!", name = "txt")
>>
>> ## But I can't get rid of this text on the device
>> ## until I refresh device or do another grid call
>> grid.remove("txt") ## still on my X1 device!
>>
>>
>> > sessionInfo()
>> R version 2.6.2 (2008-02-08)
>> i686-pc-linux-gnu
>>
>> locale:
>> LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=en_US.UTF-8;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C
>>
>> attached base packages:
>> [1] grid stats graphics grDevices utils datasets methods
>> [8] base
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--
Brian D. Ripley, [EMAIL PROTECTED]
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
[Rd] RFC for package PopCon: a popularity contest for R and packages
Hello all, I've developed a prototype package called PopCon (short for popularity contest), a package for tracking the popularity of R and its packages. I'd like this work to be similar in spirit to the Debian package popularity-contest: http://popcon.debian.org/. Once Popcon is loaded, it captures two kinds of information from the user and stores it into a cache: the names of the libraries he/she loads, and the names of symbols requested from his/her code. Once the cache is full, the goal is to flush the data to a central server for storage, free for anyone to download and analyze. That's it. Pretty simple use and works behind the scenes. You can get the prototype here: http://biostat.mc.vanderbilt.edu/twiki/pub/Main/JeffreyHorner/PopCon_0.1.tar.gz And note that flushing of the cache is NOT TURNED ON and IT WON'T FORWARD ANY DATA ANYWHERE! It only gets deleted. So, I envision all the software and data generated and stored to be licensed under a GPL and a Creative Commons license, or even public domain. Thoughts? I'm looking for volunteers, because there are many issues to hash out. Here's a few of them: 1. Obviously storing IP addresses or any bit of personal information is out, but I'm interested in generating a permanent random key of some sort so that data from the same R installs can be tracked. I'm wondering if just md5 hashing the combination of R version, platform, and IP address would be appropriate and reproducible per R install. The debian package popularity-contest has the benefit of installing an '/etc' config file and generating the key once, while I'd like PopCon users to just call 'library(PopCon)' and do nothing else. 2. I'm willing to maintain the central server and work on the infrastructure, but help will definitely be needed. Also, if there's significant interested, maybe R core would be interested in this. 3. What exactly is PopCon tracking as far as symbol names go? It currently used an R_ObjectTable object attached to the search path to capture names, but is this the best way? see http://www.omegahat.org/RObjectTables/. It's also replacing base::getHook to trap library loads. 4. What else would be interesting to track? Some folks have suggested various bits of R.Version() output. Here's what PopCon can currently do: > library(PopCon) > search() [1] ".GlobalEnv""package:PopCon"".pcUDB" [4] "package:stats" "package:graphics" "package:grDevices" [7] "package:utils" "package:datasets" "package:methods" [10] "Autoloads" "package:base" # Notice the above search entry .pcUDB. That's the R Object Table > typeof(PopCon::getCache()) [1] "character" > PopCon::getCache() [1] ".conflicts.OK" "search""::" # Now the cache contains the name 'search', which I called above, # and the double colon operator. > library(cluster) > any(PopCon::getCache()=='package:cluster') [1] TRUE # Package names are represented in the PopCon cache just like # their name on the search path. > PopCon::getCache() [1] ".conflicts.OK""search" [3] "::" "$.data.frame" [5] "$.default""$.data.frame" [7] "$.default""unique.integer" [9] "unique.numeric" "$.data.frame" [11] "$.default""unique.integer" [13] "unique.numeric" "unique.character" [15] "unique.integer" "unique.numeric" [17] "close.gzfile" "$.packageDescription2" [19] "$.default""$.data.frame" [21] "$.default""unique.integer" [23] "unique.numeric" "unique.character" [25] "unique.integer" "unique.numeric" [27] "close.gzfile" "$.packageDescription2" [29] "$.default""unique.integer" [31] "unique.numeric" "close.gzfile" [33] "names.simple.list""names.default" [35] "[.default""as.character.simple.list" [37] "as.vector.simple.list""as.vector.default" [39] "unique.character" "$.packageDescription2" [41] "$.default"">=.R_system_version" [43] "Ops.R_system_version" ">=.package_version" [45] "Ops.package_version" ">=.numeric_version" [47] ">=.package_version" "Ops.package_version" [49] ">=.numeric_version" "unlist.R_system_version" [51] "unlist.package_version" "unlist.numeric_version" [53] "unlist.default" "unlist.package_version" [55] "unlist.numeric_version" "unlist.default" [57] "as.list.R_system_version" "as.list.package_version" [59] "unique.integer" "unique.numeric" [61] "as.list.R_system_version" "as.list.package_version" [63] "unique.integer" "unique.numeric" [65] "as.list.package_version" "unique.integer" [67] "unique.numeric" "as.list.package_version" [69] "unique.integer" "unique.numeric" [71] ">=.default" "$.packageDescription2" [73] "$.default"
Re: [Rd] Rprofile.site in Windows version
You are of course right, library(tools) is not necessary.
Duncan Murdoch wrote:
> On 09/02/2008 6:44 PM, Erich Neuwirth wrote:
>> I think Rprofile.site as installed with R-2.6.2
>> contains some misleading information.
>> It contains the following lines
>>
>> # set a CRAN mirror
>> # local({r <- getOption("repos")
>> # r["CRAN"] <- "http://my.local.cran";
>> # options(repos=r)})'.
>>
>> Uncommenting these lines and changing the URL
>> will not work.
>>
>> '. at the end of the last line will break the execution.
>
> Yes, those shouldn't be there.
>
>> Furthermore
>> library(tools)
>> needs to be run before these lines can be run.
>
> Why? local, getOption, and options are all in the base package.
>
> Duncan Murdoch
>
>
--
Erich Neuwirth, University of Vienna
Faculty of Computer Science
Computer Supported Didactics Working Group
Visit our SunSITE at http://sunsite.univie.ac.at
Phone: +43-1-4277-39464 Fax: +43-1-4277-39459
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] GCV in lm.ridge (MASS) (PR#10755)
Full_Name: Andrew Robinson Version: 2.6.2 Patched (2008-02-12 r44439) OS: FreeBSD 6.3-RC1 Submission from: (NULL) (211.28.206.186) I believe that the computation for GCV is incorrect in the lm.ridge function in MASS. >From lm.ridge: GCV <- colSums((Y - X %*% coef)^2)/ (n - colSums(matrix(d^2/div, dx)))^2 The denominator does not tally with the formula on p. 141 of Ripley's Pattern Recognition & Neural Networks. I think that it should be GCV <- colSums((Y - X %*% coef)^2)/ (1 - colSums(matrix(d^2/div, dx))/n)^2 / n Also, neither formula (above) counts the intercept amongst the parameters This makes sense from the point of view that the intercept is not shrunk in ridge regression, but if it has been conditioned on for computing the residual sum of squares, then there is an argument that it should be included in the trace of the mapping matrix anyway. Thanks Andrew > sessionInfo() R version 2.6.2 Patched (2008-02-12 r44439) i386-unknown-freebsd6.3 locale: C attached base packages: [1] stats graphics grDevices utils datasets methods base other attached packages: [1] MASS_7.2-40 loaded via a namespace (and not attached): [1] rcompgen_0.1-17 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
