Re: [Rd] Multiplication (PR#8466)
Thomas Lumley wrote: >On Fri, 6 Jan 2006, [EMAIL PROTECTED] wrote: > > > >>hi - in version 2.1 the command >> >> >> >>>-2^2 >>> >>> >>gives >> >>-4 >> >>as the answer. (-2)^2 is evaluated correctly. >> >> > >So is -2^2. The precedence of ^ is higher than that of unary minus. It >may be surprising, but it *is* documented and has been in S for a long >time. > > > -thomas > > No, it's not surprising. At least to me... In the country where I grew up, I've been teached that -x^2 means -(x^2) not (-x)^2 ;-) H. -- Hervé Pagès E-mail: [EMAIL PROTECTED] Phone: (206) 667-5791 Fax: (206) 667-1319 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] formal argument "envir" matched by multiple actual arguments
In fact reg.finalizer() looks like a dangerous feature.
If the finalizer itself triggers (implicitely or
explicitely) garbage collection, then bad things happen.
In the following example, garbage collection is triggered
explicitely (using R-2.9.0):
setClass("B", representation(bb="environment"))
newB <- function()
{
ans <- new("B", bb=new.env())
reg.finalizer(a...@bb,
function(e)
{
gc()
cat("cleaning", class(ans), "object...\n")
}
)
return(ans)
}
> for (i in 1:500) {cat(i, "\n"); b1 <- newB()}
1
2
3
4
5
6
...
13
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
14
...
169
170
171
Error: not a weak reference
Error: not a weak reference
[repeat the above line thousands of times]
...
Error: not a weak reference
Error: not a weak reference
cleaning B object...
Error: SET_VECTOR_ELT() can only be applied to a 'list', not a 'integer'
Error: SET_VECTOR_ELT() can only be applied to a 'list', not a 'integer'
[repeat the above line thousands of times]
...
Error: SET_VECTOR_ELT() can only be applied to a 'list', not a 'integer'
Error: SET_VECTOR_ELT() can only be applied to a 'list', not a 'integer'
172
...
246
247
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
cleaning B object...
*** caught segfault ***
address 0x41, cause 'memory not mapped'
Traceback:
1: gc()
2: function (e) {gc()cat("cleaning", class(ans),
"object...\n")}()
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: 2
Save workspace image? [y/n/c]: n
Segmentation fault
So apparently, if the finalizer triggers garbage collection,
then we can end up with a corrupted session. Then anything can
happen, from the strange 'formal argument "envir" matched by
multiple actual arguments' error I reported in the previous post,
to a segfault. In the worse case, nothing apparently happens but
the output produced by the code is wrong.
Maybe garbage collection requests should be ignored during the
execution of the finalizer? (and more generally during garbbage
collection itself)
Cheers,
H.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Protection stack overflow
Hi,
> gctorture(TRUE)
> setGeneric("foo", function(x, y) standardGeneric("foo"))
[1] "foo"
> setMethod("foo", c("ANY", "ANY"),
+ function(x, y) cat("calling foo,ANY,ANY method\n")
+ )
Error: protect(): protection stack overflow
Sorry this is something I already reported one week ago here
https://stat.ethz.ch/pipermail/r-devel/2009-July/053973.html
but I just had a 2nd look at it and realized that the problem
can in fact be reproduced out of the .onLoad() hook. So I'm
reporting it again with a different subject.
See my sessionInfo() below. Thanks!
H.
sessionInfo()
R version 2.10.0 Under development (unstable) (2009-06-26 r48837)
x86_64-unknown-linux-gnu
locale:
[1] LC_CTYPE=en_CA.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_CA.UTF-8LC_COLLATE=en_CA.UTF-8
[5] LC_MONETARY=C LC_MESSAGES=en_CA.UTF-8
[7] LC_PAPER=en_CA.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_CA.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Inaccuracy in ?convolve
Hi, Man page for 'convolve' says: conj: logical; if 'TRUE', take the complex _conjugate_ before back-transforming (default, and used for usual convolution). The complex conjugate of 'x', of 'y', of both? In fact it seems that it takes the complex conjugate of 'y' only which is OK but might be worth mentioning because (1) conj=TRUE is the default and (2) with this default then convolve(x,y) is not the same as convolve(y,x). Note that 'convolve' is commutative with conj=FALSE and would be too if conj=TRUE was taking the complex conjugate of x _and_ y... Cheers, H. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] convolve: request for "usual" behaviour + some improvements + some fixes
Hi Martin,
Thanks for taking the time to read me. Here is a followup,
it's rather long but hopefully not too long (and not too boring) ;-)
Quoting Martin Maechler <[EMAIL PROTECTED]>:
> Thank you, Herve,
>
> > "Herve" == Herve Pages <[EMAIL PROTECTED]>
> > on Fri, 02 Feb 2007 21:30:04 -0800 writes:
>
> Herve> Last but not least: convolve2 can be made 100 times or 1000 times
faster
> Herve> than convolve by choosing a power of 2 for the length of the
fft-buffer
> Herve> (a length of 2^n is the best case for the fft, the worst case
being
when
> Herve> the length is a prime number):
...
> The typical approach here and definitely the idea of the
> original author of convolve() - would be to use nextn() here
> instead of "next_power_of_2()".
The current implementation of convolve uses an fft-buffer of length
nx + ny - 1 for "open" convolution, not nextn().
The fft-based convolution is by nature "circular". However it can be
used for "open" convolutions: the trick is to padd the input sequences
with enough zeros to avoid the overlap inherent to circular convolution.
Then the ouput sequence doesn't "look" circular anymore.
For example, if the input sequences are
X = 2 5 8
Y = 100 1 0
then the "circular" convolution of X and Y is
Z = 205 802 508
To achieve "open" convolution, it's enough to _right_ padd X and
Y with zeros:
X = 2 5 8 0
Y = 100 1 0 0
then the "circular" convolution doesn't look circular anymore (it
looks "open"):
Z = 200 802 508 5
All you need to do is to padd enough zeros to have length X (and Y)
>= nx + ny - 1. But you can add more zeros if you want: this doesn't
change the result (except that you get extra zeros in the output
sequence):
X = 2 5 8 0 0 0
Y = 100 1 0 0 0 0
Z = 200 802 508 5 0 0
The current approach of adding the strict minimum number of necessary
zeros could _at first glance_ seem reasonable since it minimizes
the amount of memory used. But the problem with this approach is that the
fft algorithm is not very good in the general case and very very bad when
the length of the sequence is a prime number: in this case it has to
perform n^2 complex multiplications so it can litterally take days or
weeks when n is a big prime number (>= 10 millions).
>
> convolve() is one of the very old R functions stemming from
> Auckland already seen in the very first R tarball that's still
> available: Dated from June 20, 1995, with most file dates from
> Jun 16/17, i.e. really of even older date, the file src/rrc/fft
> (no 'library', noR extension yet) contains definitions for 'fft', 'nextn'
> and 'convolve' where the latter was (note the ":=" for what now
> would be assignment to the base package)
>
> convolve := function (a, b, conj=F)
> {
> na <- length(a)
> nb <- length(b)
> n <- max(na, nb)
> if (nb < n)
> b <- c(b, rep(0, n - nb))
> else if (na < n)
> a <- c(b, rep(0, n - na))
> da <- fft(a)
> db <- fft(b)
> if(conj) {
> a <- da$x * db$x + da$y * db$y
> b <- - da$x * db$y + db$x * da$y
> }
> else {
> a <- da$x * db$x - da$y * db$y
> b <- da$x * db$y + db$x * da$y
> }
> fft(a, b, inv=T)$x
> }
>
> and just for historical fun here's the help file in that
> cute olde help file format:
>
> TITLE(convolve @ Fast Convolution)
> USAGE(
> convolve(a, b, conj=false)
> )
> ARGUMENTS(
> ARG(a,b @ the sequences to be convolved.)
> ARG(conj @ logical, if true the transform of LANG(b) is conjugated
> before back-transformation.)
> )
> DESCRIPTION(
> LANG(convolve) uses the Fast Fourier Transform to compute the
> convolution of the sequences given as its arguments.
> PARA
> Complex conjugation is useful when computing
> autocovariances and autocorrelations by fast convolution.
> )
> REFERENCES(
> Brillinger, D. R. (1981).
> ITALIC(Time Series: Data Analysis and Theory), Second Edition.
> San Francisco: Holden-Day.
> )
> SEEALSO(
> LANG(LINK(fft)), LANG(LINK(nextn)).
> )
If you ignore the huge bug that 'a' is replaced by 'b' during the 0-padding
operation, this one was better than the current 'convolve'. It already had
the 'conj' argument and the default for it was FALSE so, by default,
the convolve function was doing convolution, not cross-correlation
(more on this below).
But it was doing "circular" convolution only...
>
> Later I had added bits to the docu, convolve got the 'type'
> argument, Brian also fixed code and amplified the description and provided
> the alternative filter() which had hencefor been recommended
> instead of convolve for most applications.
filter() might be OK for users who want filtering but what about people
who want a convolution?
Just FYI, with:
X = 2 5 8
Y = 100 1
filter(X, Y) gives:
Z = 502 805 NA
convolve(X, Y, type="filter") gives:
Z = 208 805
and convolve(x, y, conj=FALSE, ty
[Rd] Wrong vector size reported by error message
Hi, On my system, I get the following error message: > big <- 2:(2**30) Error: cannot allocate vector of size 0 Kb Note the wrong "size 0 Kb" in the message! Cheers, H. > sessionInfo() R version 2.5.0 Under development (unstable) (2007-01-05 r40386) i686-pc-linux-gnu locale: LC_CTYPE=en_CA.UTF-8;LC_NUMERIC=C;LC_TIME=en_CA.UTF-8;LC_COLLATE=en_CA.UTF-8;LC_MONETARY=en_CA.UTF-8;LC_MESSAGES=en_CA.UTF-8;LC_PAPER=en_CA.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_CA.UTF-8;LC_IDENTIFICATION=C attached base packages: [1] "stats" "graphics" "grDevices" "utils" "datasets" "methods" [7] "base" __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Build error with last R-devel tarball
Hi, On Windows, with last R-devel tarball (r40647) from ftp://ftp.stat.math.ethz.ch/Software/R/R-devel_2007-02-04.tar.gz I get the following build error: E:\biocbld\bbs-2.0-bioc\R\src\gnuwin32> make ... ... -- Making package utils adding build stamp to DESCRIPTION installing NAMESPACE file and metadata installing R files Error in namespaceExport(ns, exports) : undefined exports :?, CRAN.packages, Rprof, Rprofmem, RShowDo c, RSiteSearch, URLdecode, URLencode, alarm, apropos, argsAnywhere, assignInNamespace, as.roman, as.p erson, as.personList, available.packages, browseEnv, browseURL, bug.report, capture.output, checkCRAN , chooseCRANmirror, citation, citEntry, citHeader, citFooter, close.socket, combn, compareVersion, co ntrib.url, count.fields, data, data.entry, dataentry, de, de.ncols, de.restore, de.setup, debugger, d emo, download.file, download.packages, dump.frames, edit, emacs, example, file_test, file.edit, find, fix, fixInNamespace, flush.console, formatOL, formatUL, getAnywhere, getFromNamespace, getS3method, glob2rx, head, head.matrix, help, help.search, help.start, history, index.search, install.packages, i nstalled.packages, limitedLabels, loadhistory, localeToCharset, ls.str, lsf.str, make.packages.html, make.socket, memory.limit, memory.size, menu, methods, mirror2html, modifyList, new.packag In addition: Warning message: S3 methods '[.getAnywhere', '[.roman', 'as.character.person', 'as.character.personList', 'as.characte r.roman', 'as.person.default', 'as.personList.default', 'as.personList.person', 'edit.data.frame', 'e dit.default', 'edit.matrix', 'edit.vignette', 'format.roman', 'head.data.frame', 'head.default', 'hea d.function', 'head.matrix', 'head.ftable', 'head.table', 'print.citation', 'print.Bibtex', 'print.cit ationList', 'print.getAnywhere', 'print.hsearch', 'print.help_files_with_topic', 'print.Latex', 'prin t.ls_str', 'print.MethodsFunction', 'print.packageDescription', 'print.packageIQR', 'print.packageSta tus', 'print.roman', 'print.sessionInfo', 'print.socket', 'print.vignette', 'prompt.data.frame', 'pro mpt.default', 'stack.data.frame', 'stack.default', 'str.POSIXt', 'str.data.frame', 'str.default', 'su mmary.packageStatus', 'tail.data.frame', 'tail.default', 'tail.function', 'tail.matrix', 'tail.ftable ', 'tail.table', 'toBibtex.citation', 'toBibtex.citationList', 'toBibtex.person', 'toBibtex [... trun cated] Execution halted make[4]: *** [E:/biocbld/bbs-2.0-bioc/R/library/utils/R/utils] Error 1 make[3]: *** [all] Error 2 make[2]: *** [pkg-utils] Error 2 make[1]: *** [rpackage] Error 1 make: *** [all] Error 2 Cheers, H. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Build error with last R-devel tarball
Quoting Prof Brian Ripley <[EMAIL PROTECTED]>: > This was fixed in SVN within a few hours. Tarballs are snapshots, please > check SVN before reporting problems. Thanks! I will check SVN before reporting problems with a tarball. Just hope that nobody will get too upset if I'm reporting a problem that just got fixed during the time I did 'svn up' and 'Send Message' though ;-) > > As I have said several times, please do not expect R-devel to build on all > platforms at all times. Of course. But please, let us know if reporting problems when they occur is still the right thing to do or not. Thanks, H. > > On Mon, 5 Feb 2007, [EMAIL PROTECTED] wrote: > > > Hi, > > > > > > On Windows, with last R-devel tarball (r40647) from > > ftp://ftp.stat.math.ethz.ch/Software/R/R-devel_2007-02-04.tar.gz > > I get the following build error: > > > > E:\biocbld\bbs-2.0-bioc\R\src\gnuwin32> make > > ... > > ... > > -- Making package utils > > adding build stamp to DESCRIPTION > > installing NAMESPACE file and metadata > > installing R files > > Error in namespaceExport(ns, exports) : undefined exports :?, > CRAN.packages, > > Rprof, Rprofmem, RShowDo > > c, RSiteSearch, URLdecode, URLencode, alarm, apropos, argsAnywhere, > > assignInNamespace, as.roman, as.p > > erson, as.personList, available.packages, browseEnv, browseURL, > bug.report, > > capture.output, checkCRAN > > , chooseCRANmirror, citation, citEntry, citHeader, citFooter, > close.socket, > > combn, compareVersion, co > > ntrib.url, count.fields, data, data.entry, dataentry, de, de.ncols, > de.restore, > > de.setup, debugger, d > > emo, download.file, download.packages, dump.frames, edit, emacs, example, > > file_test, file.edit, find, > > fix, fixInNamespace, flush.console, formatOL, formatUL, getAnywhere, > > getFromNamespace, getS3method, > > glob2rx, head, head.matrix, help, help.search, help.start, history, > > index.search, install.packages, i > > nstalled.packages, limitedLabels, loadhistory, localeToCharset, ls.str, > lsf.str, > > make.packages.html, > > make.socket, memory.limit, memory.size, menu, methods, mirror2html, > modifyList, > > new.packag > > In addition: Warning message: > > S3 methods '[.getAnywhere', '[.roman', 'as.character.person', > > 'as.character.personList', 'as.characte > > r.roman', 'as.person.default', 'as.personList.default', > 'as.personList.person', > > 'edit.data.frame', 'e > > dit.default', 'edit.matrix', 'edit.vignette', 'format.roman', > 'head.data.frame', > > 'head.default', 'hea > > d.function', 'head.matrix', 'head.ftable', 'head.table', 'print.citation', > > 'print.Bibtex', 'print.cit > > ationList', 'print.getAnywhere', 'print.hsearch', > 'print.help_files_with_topic', > > 'print.Latex', 'prin > > t.ls_str', 'print.MethodsFunction', 'print.packageDescription', > > 'print.packageIQR', 'print.packageSta > > tus', 'print.roman', 'print.sessionInfo', 'print.socket', > 'print.vignette', > > 'prompt.data.frame', 'pro > > mpt.default', 'stack.data.frame', 'stack.default', 'str.POSIXt', > > 'str.data.frame', 'str.default', 'su > > mmary.packageStatus', 'tail.data.frame', 'tail.default', 'tail.function', > > 'tail.matrix', 'tail.ftable > > ', 'tail.table', 'toBibtex.citation', 'toBibtex.citationList', > > 'toBibtex.person', 'toBibtex [... trun > > cated] > > Execution halted > > make[4]: *** [E:/biocbld/bbs-2.0-bioc/R/library/utils/R/utils] Error 1 > > make[3]: *** [all] Error 2 > > make[2]: *** [pkg-utils] Error 2 > > make[1]: *** [rpackage] Error 1 > > make: *** [all] Error 2 > > > > Cheers, > > H. > > > > __ > > 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] extracting rows from a data frame by looping over the row names: performance issues
Hi Seth,
Quoting Seth Falcon <[EMAIL PROTECTED]>:
> Herve Pages <[EMAIL PROTECTED]> writes:
> > So apparently here extracting with dat[i, ] is 300 times faster than
> > extracting with dat[key, ] !
> >
> >> system.time(for (i in 1:100) dat["1", ])
> >user system elapsed
> > 12.680 0.396 13.075
> >
> >> system.time(for (i in 1:100) dat[1, ])
> >user system elapsed
> > 0.060 0.076 0.137
> >
> > Good to know!
>
> I think what you are seeing here has to do with the space efficient
> storage of row.names of a data.frame. The example data you are
> working with has no specified row names and so they get stored in a
> compact fashion:
>
> mat <- matrix(rep(paste(letters, collapse=""), 5*30), ncol=5)
> dat <- as.data.frame(mat)
>
> > typeof(attr(dat, "row.names"))
> [1] "integer"
>
> In the call to [.data.frame when i is character, the appropriate index
> is found using pmatch and this requires that the row names be
> converted to character. So in a loop, you get to convert the integer
> vector to character vector at each iteration.
Maybe this could be avoided. Why do you need to call pmath when
the row names are integer?
In [.data.frame if you replace this:
...
if (is.character(i)) {
rows <- attr(xx, "row.names")
i <- pmatch(i, rows, duplicates.ok = TRUE)
}
...
by this
...
if (is.character(i)) {
rows <- attr(xx, "row.names")
if (typeof(rows) == "integer")
i <- as.integer(i)
else
i <- pmatch(i, rows, duplicates.ok = TRUE)
}
...
then you get a huge boost:
- with current [.data.frame
> system.time(for (i in 1:100) dat["1", ])
user system elapsed
34.994 1.084 37.915
- with "patched" [.data.frame
> system.time(for (i in 1:100) dat["1", ])
user system elapsed
0.264 0.068 0.364
but maybe I'm missing somethig...
Cheers,
H.
>
> If you assign character row names, things will be a bit faster:
>
> # before
> system.time(for (i in 1:25) dat["2", ])
>user system elapsed
> 9.337 0.404 10.731
>
> # this looks funny, but has the desired result
> rownames(dat) <- rownames(dat)
> typeof(attr(dat, "row.names")
>
> # after
> system.time(for (i in 1:25) dat["2", ])
>user system elapsed
> 0.343 0.226 0.608
>
> And you probably would have seen this if you had looked at the the
> profiling data:
>
> Rprof()
> for (i in 1:25) dat["2", ]
> Rprof(NULL)
> summaryRprof()
>
>
> + seth
>
> __
> 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] extracting rows from a data frame by looping over the row names: performance issues
Quoting [EMAIL PROTECTED]:
> In [.data.frame if you replace this:
>
> ...
> if (is.character(i)) {
> rows <- attr(xx, "row.names")
> i <- pmatch(i, rows, duplicates.ok = TRUE)
> }
> ...
>
> by this
>
> ...
> if (is.character(i)) {
> rows <- attr(xx, "row.names")
> if (typeof(rows) == "integer")
> i <- as.integer(i)
> else
> i <- pmatch(i, rows, duplicates.ok = TRUE)
> }
> ...
>
> then you get a huge boost:
>
> - with current [.data.frame
> > system.time(for (i in 1:100) dat["1", ])
>user system elapsed
> 34.994 1.084 37.915
>
> - with "patched" [.data.frame
> > system.time(for (i in 1:100) dat["1", ])
>user system elapsed
> 0.264 0.068 0.364
>
mmmh, replacing
i <- pmatch(i, rows, duplicates.ok = TRUE)
by just
i <- as.integer(i)
was a bit naive. It will be wrong if rows is not a "seq_len" sequence.
So I need to be more carefull by first calling 'match' to find the exact
matches and then calling 'pmatch' _only_ on those indices that don't have
an exact match. For example like doing something like this:
if (is.character(i)) {
rows <- attr(xx, "row.names")
if (typeof(rows) == "integer") {
i2 <- match(as.integer(i), rows)
if (any(is.na(i2)))
i2[is.na(i2)] <- pmatch(i[is.na(i2)], rows, duplicates.ok =
TRUE)
i <- i2
} else {
i <- pmatch(i, rows, duplicates.ok = TRUE)
}
}
Correctness:
> dat2 <- data.frame(aa=c('a', 'b', 'c', 'd'), bb=1:4,
row.names=c(11,25,1,3))
> dat2
aa bb
11 a 1
25 b 2
1 c 3
3 d 4
> dat2["1",]
aa bb
1 c 3
> dat2["3",]
aa bb
3 d 4
> dat2["2",]
aa bb
25 b 2
Performance:
> mat <- matrix(rep(paste(letters, collapse=""), 5*30), ncol=5)
> dat <- as.data.frame(mat)
> system.time(for (i in 1:100) dat["1", ])
user system elapsed
2.036 0.880 2.917
Still 17 times faster than with non-patched [.data.frame.
Maybe 'pmatch(x, table, ...)' itself could be improved to be
more efficient when 'x' is a character vector and 'table' an
integer vector so the above trick is not needed anymore.
My point is that something can probably be done to improve the
performance of 'dat[i, ]' when the row names are integer and 'i'
a character vector. I'm assuming that, in the typical use-case,
there is an exact match for 'i' in the row names so converting
those row names to a character vector in order to find this match
is (most of the time) a waste of time.
Cheers,
H.
> but maybe I'm missing somethig...
>
> Cheers,
> H.
>
> >
> > If you assign character row names, things will be a bit faster:
> >
> > # before
> > system.time(for (i in 1:25) dat["2", ])
> >user system elapsed
> > 9.337 0.404 10.731
> >
> > # this looks funny, but has the desired result
> > rownames(dat) <- rownames(dat)
> > typeof(attr(dat, "row.names")
> >
> > # after
> > system.time(for (i in 1:25) dat["2", ])
> >user system elapsed
> > 0.343 0.226 0.608
> >
> > And you probably would have seen this if you had looked at the the
> > profiling data:
> >
> > Rprof()
> > for (i in 1:25) dat["2", ]
> > Rprof(NULL)
> > summaryRprof()
> >
> >
> > + seth
> >
> > __
> > 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
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] extracting rows from a data frame by looping over the row names: performance issues
Quoting hadley wickham <[EMAIL PROTECTED]>:
> On 3/3/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > Quoting [EMAIL PROTECTED]:
> > > In [.data.frame if you replace this:
> > >
> > > ...
> > > if (is.character(i)) {
> > > rows <- attr(xx, "row.names")
> > > i <- pmatch(i, rows, duplicates.ok = TRUE)
> > > }
> > > ...
> > >
> > > by this
> > >
> > > ...
> > > if (is.character(i)) {
> > > rows <- attr(xx, "row.names")
> > > if (typeof(rows) == "integer")
> > > i <- as.integer(i)
> > > else
> > > i <- pmatch(i, rows, duplicates.ok = TRUE)
> > > }
> > > ...
> > >
> > > then you get a huge boost:
> > >
> > > - with current [.data.frame
> > > > system.time(for (i in 1:100) dat["1", ])
> > >user system elapsed
> > > 34.994 1.084 37.915
> > >
> > > - with "patched" [.data.frame
> > > > system.time(for (i in 1:100) dat["1", ])
> > >user system elapsed
> > > 0.264 0.068 0.364
> > >
> >
> > mmmh, replacing
> > i <- pmatch(i, rows, duplicates.ok = TRUE)
> > by just
> > i <- as.integer(i)
> > was a bit naive. It will be wrong if rows is not a "seq_len" sequence.
> >
> > So I need to be more carefull by first calling 'match' to find the exact
> > matches and then calling 'pmatch' _only_ on those indices that don't have
> > an exact match. For example like doing something like this:
> >
> > if (is.character(i)) {
> > rows <- attr(xx, "row.names")
> > if (typeof(rows) == "integer") {
> > i2 <- match(as.integer(i), rows)
> > if (any(is.na(i2)))
> > i2[is.na(i2)] <- pmatch(i[is.na(i2)], rows, duplicates.ok
> =
> > TRUE)
> > i <- i2
> > } else {
> > i <- pmatch(i, rows, duplicates.ok = TRUE)
> > }
> > }
> >
> > Correctness:
> >
> > > dat2 <- data.frame(aa=c('a', 'b', 'c', 'd'), bb=1:4,
> >row.names=c(11,25,1,3))
> > > dat2
> > aa bb
> > 11 a 1
> > 25 b 2
> > 1 c 3
> > 3 d 4
> >
> > > dat2["1",]
> > aa bb
> > 1 c 3
> >
> > > dat2["3",]
> > aa bb
> > 3 d 4
> >
> > > dat2["2",]
> > aa bb
> > 25 b 2
> >
> > Performance:
> >
> > > mat <- matrix(rep(paste(letters, collapse=""), 5*30), ncol=5)
> > > dat <- as.data.frame(mat)
> > > system.time(for (i in 1:100) dat["1", ])
> > user system elapsed
> > 2.036 0.880 2.917
> >
> > Still 17 times faster than with non-patched [.data.frame.
> >
> > Maybe 'pmatch(x, table, ...)' itself could be improved to be
> > more efficient when 'x' is a character vector and 'table' an
> > integer vector so the above trick is not needed anymore.
> >
> > My point is that something can probably be done to improve the
> > performance of 'dat[i, ]' when the row names are integer and 'i'
> > a character vector. I'm assuming that, in the typical use-case,
> > there is an exact match for 'i' in the row names so converting
> > those row names to a character vector in order to find this match
> > is (most of the time) a waste of time.
>
> But why bother? If you know the index of the row, why not index with
> a numeric vector rather than a string? The behaviour in that case
> seems obvious and fast.
Because if I want to access a given row by its key (row name) then I _must_
use a string:
> dat=data.frame(aa=letters[1:6], bb=1:6,
row.names=as.integer(c(51, 52, 11, 25, 1, 3)))
> dat
aa bb
51 a 1
52 b 2
11 c 3
25 d 4
1 e 5
3 f 6
If my key is "1":
> dat["1", ]
aa bb
1 e 5
OK
I can't use a numeric index:
> dat[1, ]
aa bb
51 a 1
Not what I want!
With a big data frame (e.g. 10**6 rows), every time I do 'dat["1", ]'
I'm charged the price of the coercion from a 10**6-element character
vector to an integer vector. A very high (and unreasonable) price that
could be easily avoided.
You could argue that I can still work around this by extracting
'attr(dat, "row.names")' myself, check its mode, and then, if its
mode is integer, use 'match' to find the position (i2) of my key in
the row.names, then finally call 'dat[i2, ]'. Is is unreasonable to
expect [.data.frame to do that for me?
Cheers,
H.
>
> Hadley
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Unexpected result of as.character() and unlist() applied to a data frame
Hi,
> dd <- data.frame(A=c("b","c","a"), B=3:1)
> dd
A B
1 b 3
2 c 2
3 a 1
> unlist(dd)
A1 A2 A3 B1 B2 B3
2 3 1 3 2 1
Someone else might get something different. It all depends on the
values of its 'stringsAsFactors' option:
> dd2 <- data.frame(A=c("b","c","a"), B=3:1, stringsAsFactors=FALSE)
> dd2
A B
1 b 3
2 c 2
3 a 1
> unlist(dd2)
A1 A2 A3 B1 B2 B3
"b" "c" "a" "3" "2" "1"
Same thing with as.character:
> as.character(dd)
[1] "c(2, 3, 1)" "c(3, 2, 1)"
> as.character(dd2)
[1] "c(\"b\", \"c\", \"a\")" "c(3, 2, 1)"
Bug or "feature"?
Note that as.character applied directly on dd$A doesn't
have this "feature":
> as.character(dd$A)
[1] "b" "c" "a"
> as.character(dd2$A)
[1] "b" "c" "a"
Cheers,
H.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Unexpected alteration of data frame column names
Hi,
Thanks to both for your answers!
Quoting Marc Schwartz <[EMAIL PROTECTED]>:
> On Thu, 2007-05-17 at 10:54 +0100, Prof Brian Ripley wrote:
> > To add to Marc's detective work. ?"[.data.frame" does say
> >
> > If '[' returns a data frame it will have unique (and non-missing)
> > row names, if necessary transforming the row names using
> > 'make.unique'. Similarly, column names will be transformed (if
> > columns are selected more than once).
> >
> > Now, an 'e.g.' in the parenthetical remark might make this clearer (since
> > added), but I don't see why this was 'unexpected' (or why this is an issue
It all depends whether you care about consistency or not. Personnally
I do. Yes documenting inconsistencies is better than nothing but is not
always enough to make the language predictable (see below).
So, according to ?"[.data.frame", column names will be transformed (if
columns are selected more than once). OK.
Personnally, I can see ony 2 reasonable semantics for 'df[ ]' or 'df[ , ]':
(1) either it makes an exact copy of your data frame (and this is not
only true for data frames: unless documented otherwise one can
expect x[] to be the same as x),
(2) either you consider that it is equivalent to 'df[names(df)]' for
the former and to 'df[ , names(df)]' for the latter.
So it seems that for 'df[ ]', we have semantic (1):
> df=data.frame(aa=LETTERS[1:3],bb=3:5,aa=7:5,check.names=FALSE)
> df
aa bb aa
1 A 3 7
2 B 4 6
3 C 5 5
> df[]
aa bb aa
1 A 3 7
2 B 4 6
3 C 5 5
Since we have duplicated colnames, 'df[names(df)]' will select
the first column twice and rename it (as documented):
> df[names(df)]
aa bb aa.1
1 A 3A
2 B 4B
3 C 5C
Good!
Now with 'df[ , ]', I still maintain that this is unexpected:
> df[ , ]
aa bb aa.1
1 A 37
2 B 46
3 C 55
This is a mix of semantic (1) and semantic (2): 3rd column has been renamed
but its data are the _original_ data. With semantic (2), you would get this:
> df[ , names(df)]
aa bb aa.1
1 A 3A
2 B 4B
3 C 5C
Also the fact that 'df[something]' doesn't behave like 'df[,something]'
is IMHO another inconsistency...
Hope you don't mind if I put this back on R-devel which is probably
the right place to discuss the language semantic.
Cheers,
H.
>
> > for R-devel).
> >
> > On Tue, 15 May 2007, Marc Schwartz wrote:
> >
> > > On Mon, 2007-05-14 at 23:59 -0700, Herve Pages wrote:
> > >> Hi,
> > >>
> > >> I'm using data.frame(..., check.names=FALSE), because I want to create
> > >> a data frame with duplicated column names (in the real life you can get
> such
> > >> data frame as the result of an SQL query):
> >
> > That depends on the interface you are using.
> >
> > >> > df <- data.frame(aa=1:5, aa=9:5, check.names=FALSE)
> > >> > df
> > >> aa aa
> > >> 1 1 9
> > >> 2 2 8
> > >> 3 3 7
> > >> 4 4 6
> > >> 5 5 5
> > >>
> > >> Why is [.data.frame changing my column names?
> > >>
> > >> > df[1:3, ]
> > >> aa aa.1
> > >> 1 19
> > >> 2 28
> > >> 3 37
> > >>
> > >> How can this be avoided? Thanks!
> > >>
> > >> H.
> > >
> > > Herve,
> > >
> > > I had not seen a reply to your post, but you can review the code for
> > > "[.data.frame" by using:
> > >
> > > getAnywhere("[.data.frame")
> > >
> > > and see where there are checks for duplicate column names in the
> > > function.
> > >
> > > That is going to be the default behavior for data frame
> > > subsetting/extraction and in fact is noted in the 'ONEWS' file for R
> > > version 1.8.0:
> > >
> > > - Subsetting a data frame can no longer produce duplicate
> > > column names.
> > >
> > > So it has been around for some time (October of 2003).
> > >
> > > In terms of avoiding it, I suspect that you would have to create your
> > > own version of the function, perhaps with an additional argument that
> > > enables/disables that duplicate column name checks.
> > >
> > > I have not however considered the broader functional implications of
> > > doing so however, so be vewwy vewwy careful here.
> >
> > Namespace issues would mean that your version would hardly ever be used.
>
> I suspected that namespaces might be an issue here, but had not pursued
> that line of thinking beyond an initial 'gut feel'.
>
> Thanks,
>
> Marc
>
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] pairlist objects
Hi,
?pairlist gives no explanation about what exactly is the difference
between a pairlist and a list (except that a pairlist of length 0
is 'NULL'). So, what's a pairlist?
class(.Options)
[1] "pairlist"
Some strange things about the "pairlist" type:
> showClass("pairlist")
Error in getClass(Class) : "pairlist" is not a defined class
Why the above doesn't work? It works for "list":
> showClass("list")
No Slots, prototype of class "list"
Extends: "vector"
> is.list(.Options)
[1] TRUE
> is.vector(.Options)
[1] FALSE
This doesn't make sense! If 'x' is a list, then it should be considered
a vector too.
Subsetting a pairlist with [] doesn't produce a pairlist:
> class(.Options[1:3])
[1] "list"
Yes, this one is documented, but still...
Cheers,
H.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] slots of type "double"
Hi,
Any idea why S4 doesn't allow slots of type "double"?
> setClass("A", representation(a="double"))
Error in makePrototypeFromClassDef(properties, ClassDef, immediate, where) :
in making the prototype for class "A" elements of the prototype failed to
match the corresponding slot class: a (class double )
"numeric", "integer", "character", "complex", "raw", etc... they all work
but "double" doesn't. Any reason for this strange exception?
Thanks!
H.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Pb with lapply()
Hi,
If needed, lapply() tries to convert its first argument into a list
before it starts doing something with it:
> lapply
function (X, FUN, ...)
{
FUN <- match.fun(FUN)
if (!is.vector(X) || is.object(X))
X <- as.list(X)
.Internal(lapply(X, FUN))
}
But in practice, things don't always seem to "work" as suggested by
this code (at least to the eyes of a naive user).
I have defined an "as.list" method for my S4 class "A":
> setClass("A", representation(data="list"))
[1] "A"
> setMethod("as.list", "A", function(x, ...) [EMAIL PROTECTED])
Creating a new generic function for "as.list" in ".GlobalEnv"
[1] "as.list"
Testing it:
> a <- new("A", data=list(8, 2:0))
> as.list(a)
[[1]]
[1] 8
[[2]]
[1] 2 1 0
OK.
But lapply() doesn't work on 'a':
> lapply(a, typeof)
Error in as.vector(x, "list") : cannot type 'S4' coerce to vector
I still have to do the 'as.list(a)' part myself for things to work:
> lapply(as.list(a), typeof)
[[1]]
[1] "double"
[[2]]
[1] "integer"
Seems like using force() inside lapply() would solve the problem:
lapply2 <- function(X, FUN, ...)
{
FUN <- match.fun(FUN)
if (!is.vector(X) || is.object(X))
X <- force(as.list(X))
.Internal(lapply(X, FUN))
}
It works now:
> lapply2(a, typeof)
[[1]]
[1] "double"
[[2]]
[1] "integer"
Cheers,
H.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Pb with lapply()
Hi Gabor, Quoting Gabor Grothendieck <[EMAIL PROTECTED]>: > The problem of promises not being evaluated in > lists has been discussed before. > > I think its fixed in the development version of R. See > r44139 on Jan 24, 2008 in http://developer.r-project.org/R.svnlog.2007 > I'm using R-devel r44238 and the problem is still here. Cheers, H. > sessionInfo() R version 2.7.0 Under development (unstable) (2008-01-29 r44238) x86_64-unknown-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] stats graphics grDevices utils datasets methods base __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Cannot link mypackage to 2 other packages
Hi, I need to link mypackage to 2 other packages so I can call some C functions defined in these 2 packages from mine. I've tried Depends: packageA, packageB LinkingTo: packageA, packageB as suggested by the "5.4 Registering native routines" section of the "Writing R Extensions" manual but then only packageA is seen at compilation time (gcc is called with -I"/some/path/to/packageA/include" only). I've also tried Depends: packageA, packageB LinkingTo: packageA LInkingTo: packageB but this time only packageB is seen at compilation time. How can I link mypackage to both packageA and packageB? Thanks! H. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Cannot link mypackage to 2 other packages
Quoting Prof Brian Ripley <[EMAIL PROTECTED]>: What platform? 64-bit openSUSE Linux [EMAIL PROTECTED]:~> uname -a Linux george1 2.6.22.12-0.1-default #1 SMP 2007/11/06 23:05:18 UTC x86_64 x86_64 x86_64 GNU/Linux R version 2.8.0 Under development (unstable) (2008-07-07 r46046) We've seen a similar report that said the problem was on Windows only. Like this one, it had nothing to reproduce. Do you want me to send you the packages or to put them somewhere on our website? Thanks! H. On Wed, 6 Aug 2008, [EMAIL PROTECTED] wrote: Hi, I need to link mypackage to 2 other packages so I can call some C functions defined in these 2 packages from mine. I've tried Depends: packageA, packageB LinkingTo: packageA, packageB as suggested by the "5.4 Registering native routines" section of the "Writing R Extensions" manual but then only packageA is seen at compilation time (gcc is called with -I"/some/path/to/packageA/include" only). I've also tried Depends: packageA, packageB LinkingTo: packageA LInkingTo: packageB but this time only packageB is seen at compilation time. How can I link mypackage to both packageA and packageB? Thanks! H. __ 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] Recent snapshot tarballs of R-devel don't compile
Hi, Trying to compile one of the latest snapshot tarballs of R-devel gives me the following error (64-bit openSUSE 10.3): ... make[2]: Entering directory `/loc/home/biocbuild/bbs-2.4-bioc/R/src/library/Recommended' make[2]: *** No rule to make target `VR.ts', needed by `stamp-recommended'. Stop. make[2]: Leaving directory `/loc/home/biocbuild/bbs-2.4-bioc/R/src/library/Recommended' make[1]: *** [recommended-packages] Error 2 make[1]: Leaving directory `/loc/home/biocbuild/bbs-2.4-bioc/R/src/library/Recommended' make: *** [stamp-recommended] Error 2 Maybe because these tarballs don't contain the symlinks that are normally defined in the src/library/Recommended/ folder? Cheers, H. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] callNextMethod() doesn't pass down arguments
Hi,
According to its man page, callNextMethod() (called with
no argument) should call the next method "with the arguments
to the current method passed down to the next method".
But, for the "[[" and "[" generics (primitives), the argument
after the dots doesn't seem to be passed down:
setClass("A", representation(thing="ANY"))
setClass("B", contains="A")
setMethod("[[", "A",
function(x, i, j, ..., exact=TRUE) return(exact))
setMethod("[[", "B",
function(x, i, j, ..., exact=TRUE) callNextMethod())
b <- new("B")
b[[3]]
[1] TRUE
b[[3, exact=FALSE]]
[1] TRUE
setMethod("[", "A",
function(x, i, j, ..., drop=TRUE) return(drop))
setMethod("[", "B",
function(x, i, j, ..., drop=TRUE) callNextMethod())
b[3]
[1] TRUE
b[3, drop=FALSE]
[1] TRUE
I tried this with R 2.8.0 and 2.9.0 (r47727).
Cheers,
H.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] "names<-" doesn't raise an error
Hi,
When a method is not defined for an object, you
expect to get an error. But this is not the case for
"names<-". You can use "names<-" on any S4 object: it
will remain silent, giving you the impression that it
actually did something:
setClass("A", representation(vals="numeric"))
setMethod("names", "A", function(x) names(x...@vals))
> vals <- 8:2
> names(vals) <- letters[1:7]
> a <- new("A", vals=vals)
> names(a)
[1] "a" "b" "c" "d" "e" "f" "g"
> names(a) <- LETTERS[1:7] # no error
> names(a)
[1] "a" "b" "c" "d" "e" "f" "g"# nothing has changed
Shouldn't "names<-" return an error like "[" or "[<-" do
in such situation?
> a[2]
Error in a[2] : object of type 'S4' is not subsettable
> a[2] <- 55
Error in a[2] <- 55 : object of type 'S4' is not subsettable
That would make it more convenient to implement classes where
instances have immutable names. For now I need to use the
following workaround:
setReplaceMethod("names", "A", function(x, value) stop("cannot set
my names"))
> names(a) <- LETTERS[1:7]
Error in `names<-`(`*tmp*`, value = c("A", "B", "C", "D", "E", "F", "G" :
cannot set my names
but that shouldn't be necessary.
Thanks!
H.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] bug in classesToAM()
Hi,
I can't get the non-abbreviated class names of the
rows and the cols of the Adjacency Matrix:
setClass("ClassWithALongName")
setClass("SubclassOfClassWithALongName",
contains="ClassWithALongName")
Trying all possible values for 'abbreviate' (with R-2.9.0):
classesToAM("SubclassOfClassWithALongName", abbreviate=0)
SubclassOfClassWithALongName ClassWithALongName
SOCW0 1
CWAL0 0
classesToAM("SubclassOfClassWithALongName", abbreviate=1)
SOCW CWAL
SubclassOfClassWithALongName01
ClassWithALongName 00
classesToAM("SubclassOfClassWithALongName", abbreviate=2)
SOCW CWAL
SOCW01
CWAL00
classesToAM("SubclassOfClassWithALongName", abbreviate=3)
SOCW CWAL
SubclassOfClassWithALongName01
ClassWithALongName 00
This does not reflect what the man page is saying: "values
0, 1, 2, or 3 abbreviate neither, rows, columns or both".
Cheers,
H.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Pb with contrib.url() (PR#9131)
Hi lists,
Recently I needed to download a few R packages for Unix, Windows
and Mac OS X. The idea was to put them all together on a USB key
in order to be able to install them on systems without network connection.
It worked fine for the "src" and "win.binary" packages but I had the
following problems with the "mac.binary" packages:
> download.packages("XML", destdir=".", type="mac.binary")
Warning: unable to access index for repository
http://cran.fhcrc.org/bin/macosx/x86_64/contrib/2.3
Warning in download.packages("XML", destdir = ".", type =
"mac.binary") :
no package 'XML' at the repositories
[,1] [,2]
The pb seems to be in contrib.url():
> contrib.url(getOption("repos"), "mac.binary")
[1] "http://cran.fhcrc.org/bin/macosx/x86_64/contrib/2.3";
I'm using R 2.3.1:
> sessionInfo()
Version 2.3.1 (2006-06-01)
x86_64-unknown-linux-gnu
attached base packages:
[1] "methods" "stats" "graphics" "grDevices" "utils"
"datasets"
[7] "base"
The same pb occurs with R devel (r38641).
Cheers,
H.
--
Hervé Pagès
E-mail: [EMAIL PROTECTED]
Phone: (206) 667-5791
Fax: (206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] install.packages(,type="source") broken on Windows
Hi,
On Windows, 'install.packages(,type="source")' displays the same output
than 'R CMD INSTALL --help' and doesn't install anything...
This is with R version 2.4.0 alpha (2006-09-06 r39158).
> install.packages('cat',type='source')
trying URL 'http://cran.cnr.Berkeley.edu/src/contrib/cat_0.0-6.tar.gz'
Content type 'application/x-gzip' length 22914 bytes
opened URL
downloaded 22Kb
Unknown option: configure-args
Usage: R CMD INSTALL [options] pkgs
Install the add-on packages specified by pkgs into the default R library
tree (/library) or the tree specified via '--library'. The
elements of pkgs can be relative or absolute paths to directories with
the package (bundle) sources, or to gzipped package 'tar' archives.
Then optionally pack the installed package into a zip file.
Options:
-h, --helpprint short help message and exit
-v, --version print version info and exit
-c, --clean remove all files created during installation
--fakedo minimal install for testing purposes
--unsafe install on top of any existing installation
-d, --debug [x] turn on shell and build-help debugging
-l, --library=LIB install packages to library tree LIB
--docs=TYPE type(s) of documentation to build and install
--with-package-versions
allow for multiple versions of the same package
--use-zip-datacollect data files in zip archive
--use-zip-helpcollect help and examples into zip archives
--use-zip combine '--use-zip-data' and '--use-zip-help'
--auto-zipselect whether to zip automatically
--build zip-up the installation. Implies --auto-zip
TYPE can be "none" or "normal" or "chm" (the default) or "all", or
a comma-separated list of one or more of
'txt', 'html', 'latex', "example' and 'chm'.
Report bugs to <[EMAIL PROTECTED]>.
The downloaded packages are in
c:\temp\RtmpoKYvqb\downloaded_packages
updating HTML package descriptions
H.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Strange behaviour of the [[ operator (PR#9263)
Hi Duncan, This is even more confusing with a matrix: > x <- matrix(5:-6, 3) > x [,1] [,2] [,3] [,4] [1,]52 -1 -4 [2,]41 -2 -5 [3,]30 -3 -6 > x[invisible(2),3] [1] -2 > x[2,invisible(3)] > .Last.value [1] -2 Thanks, H. Quoting [EMAIL PROTECTED]: > On 9/29/2006 9:06 PM, Herve Pages wrote: > > Hi, > > > > This looks like a bug: > > > > > a <- list(b=5) > > > a[['b']] > > [1] 5 > > > a[[t<-'b']] > > > > Nothing gets printed! > > > > I need to use parenthesis to see the expected result: > > > > > a[[(t<-'b')]] > > [1] 5 > > Yes, I agree it looks like a bug, and it's still there in R-devel. The > problem is that the assignment sets the R_Visible flag to false, and the > indexing never sets it to true. The same problem happens with a[t <- > 'b'], whether a is a list or not: > > > a <- c(b=5, c=6, d=7) > > a[t <- 'b'] > > .Last.value > b > 5 > > Duncan Murdoch > > __ > 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
