similar to: replicating lists (fwd) (PR#907)

Hi Everyone, At the moment it is not possible to replicate complex lists, but only simple ones: > rep(list(fred = 1:10), 10) # works fine > rep(list(fred = 1:10, happy = "squash"), 10) Error in rep(list(fred = 1:10, happy = "squash"), 10) : Unimplemented feature in rep There is nothing in ?rep that suggests that the latter should not work, and I think it would

Hi everyone, Can I suggest the following cosmetic change to cut.default (R-1.3.1), to adjust the labels in the case that include.lowest = TRUE: arrow:dma0jcr% diff -u cut.R my.cut.R --- cut.R Tue Nov 13 12:28:35 2001 +++ my.cut.R Tue Nov 13 12:35:16 2001 @@ -25,6 +25,11 @@ ch.br[-nb], ",", ch.br[-1], if(right)"]"

Hi Everyone, I have modified my version of R-1.4.1 to include choleski with pivoting (like in Splus). I thought R-core might consider including this in the next version of R, so I give below the steps required to facilitate this. 1. Copied Linpack routine "dchdc.f" into src/appl 2. Inserted line F77_SUBROUTINE(dchdc) in src/appl/ROUTINES 3. Inserted "dchdc.f" into

Hi everyone, Is there any reason why we should not automatically coerce a factor supplied as an argument to col in a plotting function? The following modification (to R-1.6.1) seems pretty harmless > plot.xy function (xy, type, pch = 1, lty = "solid", col = par("fg"), bg = NA, cex = 1, ...) { if (is.factor(col)) col <- codes(col)

Hi everyone, There is no mention in ?new.env (R-1.6.0) of what the effect of setting the hash argument of new.env() actually does. What does it mean in performance terms to say that "the environment will be hashed"? Thanks, Jonathan. -- Jonathan Rougier Science Laboratories Department of Mathematical Sciences South Road University of Durham

Hi everyone, I do a lot of work with large variance matrices, and I like to use "crossprod" for speed and to keep everything symmetric, i.e. I often compute "crossprod(Q %*% t(A))" for "A %*% Sigma %*% t(A)", where "Sigma" decomposes as "t(Q) %*% Q". I notice in the code that "crossprod", current definition > crossprod function (x,

Hi everyone, Can I suggest an addition to the help page for logical AND and OR, indicating the behaviour of NA (which is currently not mentioned at all). I think something simple like an extra paragraph in Details, eg \code{NA} is a valid logical object. Where a component of \code{x} or \code{y} is \code{NA}, the result will be \code{NA} if the outcome is ambiguous. In other words \code{NA

Hi everyone, Can I suggest the following modification of outer for R-1.3, in the interests of speed and size of calculation: ******************************************************************* "outer" <- function (X, Y, FUN = "*", ...) { no.nx <- is.null(nx <- dimnames(X <- as.array(X))) dX <- dim(X) no.ny <- is.null(ny <- dimnames(Y <-

ripley@stats.ox.ac.uk wrote: > > On Tue, 14 May 2002, Dirk Eddelbuettel wrote: > > > With a (late prerelease of) 1.5.0 on Windows, using sprintf on NaN > > yields garbage when the number of decimal is specified while it > > works fine for NA: > > > > > sprintf("%.2f", NA) > > [1] "0.00" > > I get that on Linux too, but

Hi everyone, I've noticed that the methods function is incomplete. The obvious example is if I write a function "$.foo", it is not picked up by methods: > "$.foo" <- function(object, name) get(name, envir=object[[1]]) > "$<-.foo" <- function(object, name, value) {assign(name, value, envir=object[[1]]); object} > happy <-

Hi everyone, Can I suggest an additional output component in cancor, from package mva? It would be useful to have the number of canonical correlation vectors, equivalently the rank of the covariance between x and y (label "rank"). This would usually be min(dx, dy), where dx and dy have already been computed for the svd function, but there might be situations where it was less than

Hi Everyone, We have just upgraded to R-1.2.1, and I note, in contrast to R-1.1.1, that ctest is now loaded automatically. The mechanism for this is to create a .First function in base: .First <- function() { require("ctest", quietly=TRUE) } Now I don't want ctest, but I find that simply putting if (length(grep("ctest", search()))) detach(package:ctest) into

Can I suggest that in cov and cor the lines if (is.data.frame(x)) x <- as.matrix(x) if (is.data.frame(y)) y <- as.matrix(y) be replaced by if (is.data.frame(x)) x <- data.matrix(x) # coerce logical and factors if (is.data.frame(y)) y <- data.matrix(y) # likewise This would allow things like > data(iris) > cor(iris) which

According to the assign helpfile (0.90.1) the "assign" function is function (x, value, pos = -1, envir = sys.frame(sys.parent()), inherits = FALSE, immediate = TRUE) which is not quite the implementation, which is function (x, value, pos = -1, envir = pos.to.env(pos), inherits = FALSE, immediate = TRUE) This seems to have the following interesting effect. "short.fun"

The following gives an immediate segmentation fault, v 0.90.1 "fred" <- function(x) { print(x); Recall(x-1)} fred(0) # segmentation fault at recursion 831 Obviously this recursion is non-terminating, but shouldn't it be caught and reported at some limit? In 0.64.1 we had Error: protect(): stack overflow at recursion 831. Cheers, Jonathan. Jonathan Rougier

Hi Everyone, I have a piece of C code that uses R_alloc, and so I set DUP=TRUE in the call using ".C". As I understand it this takes a copy of each object passed to my function. If these objects are large then this could be expensive. My question is, if I rewrote the code to use .Call, would I avoid this duplication by using the objects themselves (they are not modified in the code)

Might it be possible to tighten the definition of "is.qr". I noticed that after I mistakenly typed example(lm) # make lm object named lm.D9 qr.Q(lm.D9) which exhausted the heap memory and produced two warning messages. As an object of class "lm" has a "qr" component, "is.qr" failed to detect that "lm.D9" was not a "qr" object. The

Hi Everyone, Is there a simple way to force nlm to take larger initial steps? Setting print.level = 2 allows me to inspect the step size at each iteration, but I appear not to have made any appreciable impact on it by changing values of typsize, fscale, steptol or stepmax. The steps repeatedly come out tiny, 1e-9 typically, and the algorithm is terminating not because the gradient is zero (it

> From: Thomas Lumley > > On Sun, 30 Oct 2005, Jonathan Rougier wrote: > > > I'm not sure about this. Perhaps I am a dinosaur, but my feeling is > > that if people are writing functions in R that might be subject to > > simple operations like outer products, then they ought to be writing > > vectorised functions! > > I would agree. How about an

Could someone confirm, please, that this bug report and its proposed fix are being checked? 1. Is my analysis (message below) about right? 2. Is my proposed patch (attached) about right? 3. Is this being addressed for "rc8" (or whatever) and its successors? Many thanks. -- : David Lee I.T. Service : : Senior Systems Programmer