similar to: Data Frame Indexing

Hi, Both vapply() and sapply() support the 'USE.NAMES' argument. According to the man page: USE.NAMES: logical; if ?TRUE? and if ?X? is character, use ?X? as ?names? for the result unless it had names already. But if 'X' has names already and 'USE.NAMES' is FALSE, it's not clear what will happen to the names. Are they going to propagate to the result

Changing the vapply() behavior makes sense in principle. I analyzed the CRAN code base using the R parser and found 143 instances of calling vapply with USE.NAMES=FALSE. These would need to be inspected to understand the consequences of the change. For reference: /AzureML/R/datasets.R:226 /BBmisc/R/toRangeStr.R:33 /DBI/R/DBDriver.R:205 /Kmisc/R/str_rev.R:37 /Matrix/R/diagMatrix.R:98

Hi all Sorry for the confusing title. I noticed the following inconsistency: If i have a function that returns a named list with 2 (or more) elements, then using 'vapply' retains the names of the elements: > vapply(1:3, function(x) list("foo" = "bar", "hello" = "world"), > vector("list", 2)) [,1] [,2] [,3] foo

The documentation of ?lapply includes: > lapply and vapply are primitive functions. However, both evaluate to FALSE in `is.primitive()`: is.primitive(vapply) #FALSE is.primitive(lapply) #FALSE It appears that they are not primitives and that the documentation might be outdated. Thank you for your time and work. Cole Miller P.S. During research, my favorite `help()` is

Friends I clearly donot understand how sapply and vapply work. What I have is a function that returns a matrix with an indeterminate number of rows (some times zero) but a constant number of columns. I cannot reliably use an apply function to assemble the matrices into a matrix. I am not sure it is possible. I can demonstrate the core of my confusion with this simple code. A.f <-

On 1/20/20 12:33 PM, Martin Maechler wrote: > > It's really something that should be discussed (possibly not > here, .. but then I've started it here ...). > > The NEWS for R 3.0.0 contain (in NEW FEATURES) : > > * Functions rbinom(), rgeom(), rhyper(), rpois(), rnbinom(), > rsignrank() and rwilcox() now return integer (not double) > vectors.

vapply <- function(X, FUN, FUN.VALUE, ..., USE.NAMES = TRUE) { FUN <- match.fun(FUN) if(!is.vector(X) || is.object(X)) X <- as.list(X) .Internal(vapply(X, FUN, FUN.VALUE, USE.NAMES)) } This is an implementor question. Basically, what happened to the '...' args in the call to the .Internal? cf lapply:, where the ... is passed. lapply <- function (X, FUN, ...)

Hi all, This is the first time I'm writing to R-devel, and this time I'm just asking for the purpose for a certain line of code in stats::as.hclust.dendrogram, which comes up as I'm trying to fix dendextend. The line in question is at line 128 of dendrogram.R in R-3.3.3, at stats::as.hclust.dendrogram: stopifnot(length(s) == 2L, all( vapply(s, is.integer, NA) )) Is there any

The following code seems to contain an inconsistency in the behavior of vapply(). Am I missing something here? ## This function assumes v is a 3d vector, beta a scalar. f3d <- function(v,beta) { v+beta } ## This expression applies f3d to a vector of scalars, and ## specifies the template 'array(10,3)' for the return value. dat <- vapply(seq(0,1,length=10), function(beta) {

The algorithm does make a differece. You can use Kahan's summation algorithm (https://en.wikipedia.org/wiki/Kahan_summation_algorithm) to reduce the error compared to the naive summation algorithm. E.g., in R code: naiveSum <- function(x) { s <- 0.0 for(xi in x) s <- s + xi s } kahanSum <- function (x) { s <- 0.0 c <- 0.0 # running compensation for lost

I just got a new Windows laptop (i7, 10th generation CPU), installed 'Windows Subsystem for Linux 2' and then installed Ubuntu 20.04 and used 'apt-get install' to install packages that the R build seems to require. In particular, I am using gcc version 9.3.0. The build went without a hitch but the tests showed that deparse(1e-16) produced "1.00000000000000e-16" instead

On Wed, 18 Nov 2020 at 10:26, Tomas Kalibera <tomas.kalibera at gmail.com> wrote: > > On 11/17/20 9:34 PM, Bill Dunlap wrote: > > I just got a new Windows laptop (i7, 10th generation CPU), installed > > 'Windows Subsystem for Linux 2' and then installed Ubuntu 20.04 and > > used 'apt-get install' to install packages that the R build seems > > to

There turn out to be a few more things to fix. One problem is easy to solve: vapply() needs a third argument specifying the type of the return value. (Can we have unit tests for tab completion?) The other problem is harder: `comps` defaults to an empty string, and you can't have a symbol consisting of an empty string, because this value is internally reserved for missing function arguments.

Not paying close attention to detail, I entered the equivalent of pstr<-c("b1=200", "b2=50", "b3=0.3") when what I wanted was pnum<-c(b1=200, b2=50, b3=0.3) There was a list thread in 2010 that shows how to deal with un-named vectors, but the same lapply solution doesn't seem to work here i.e., pnum<-lapply(pstr, as.numeric) or similar vapply

Dear list, I am a little confused as to when to use apply, sapply, tapply, vapply, replicate. I've encountered this several times, This is time, this is what I am working on, mat <- matrix(c(seq(from=1, to=10), rnorm(10)), ncol=2) a=1; b=5 newfun <- function(x, y, a, b) { x*y+a+b } sapply(i=1:10, newfun(x=mat[i, 1], y=mat[i, 2], a=a, b=b)) Error in match.fun(FUN) : argument

Could your code use vapply instead of sapply? vapply forces you to declare the type and dimensions of FUN's output and stops if any call to FUN does not match the declaration. It can use much less memory and time than sapply because it fills in the output array as it goes instead of calling lapply() and seeing how it could be simplified. Bill Dunlap TIBCO Software wdunlap tibco.com On Tue,

Several bugs are present in R-2.15.3 and R-alpha due to naive copying of list elements. The bug below is due to naive copying in subset.c (with similar bugs for matrices and arrays): a<-list(c(1,2),c(3,4),c(5,6)) b<-a[2:3] a[[2]][2]<-9 print(b[[1]][2]) Naive copying in mapply.c leads to the following bug: X<-1+1 f<-function(a,b) X A<-mapply(f,c(1,2,3),c(4,5,6),SIMPLIFY=FALSE)

Quite possibly, and I?ll look into that. Aside from the work I was doing, however, I wonder if there is a way such that sapply could avoid the overhead of having to call the identical function to determine the conditional path. From: William Dunlap [mailto:wdunlap at tibco.com] Sent: Tuesday, March 13, 2018 12:14 PM To: Doran, Harold <HDoran at air.org> Cc: Martin Morgan <martin.morgan

FYI, in R devel (to become 3.5.0), there's isFALSE() which will cut some corners compared to identical(): > microbenchmark::microbenchmark(identical(FALSE, FALSE), isFALSE(FALSE)) Unit: nanoseconds expr min lq mean median uq max neval identical(FALSE, FALSE) 984 1138 1694.13 1218.0 1337.5 13584 100 isFALSE(FALSE) 713 761 1133.53 809.5 871.5

>>>>> Berry, Charles <ccberry at ucsd.edu> >>>>> on Tue, 1 May 2018 16:43:18 +0000 writes: >> On May 1, 2018, at 6:11 AM, Therneau, Terry M., Ph.D. via R-devel <r-devel at r-project.org> wrote: >> >> A user sent me an example where coxph fails, and the root of the failure is a case where names(mf) is not equal to the