similar to: lapply and vapply Primitive Documentation

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

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, ...)

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) {

I think the discussion of this issue has gotten more complicated than necessary. First, there really is a bug. You can see this also by the fact that delayed warning messages are wrong. For instance, in R-3.1.2: > lapply(c(-1,2,-1),sqrt) [[1]] [1] NaN [[2]] [1] 1.414214 [[3]] [1] NaN Warning messages: 1: In FUN(c(-1, 2, -1)[[3L]], ...) : NaNs produced 2: In

>>>>> Henrik Bengtsson <henrik.bengtsson at gmail.com> >>>>> on Tue, 13 Mar 2018 10:12:55 -0700 writes: > 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

On 12/16/2014 08:20 PM, Mick Jordan wrote: > 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

> -----Original Message----- > From: R-devel [mailto:r-devel-bounces at r-project.org] On Behalf Of Dean Attali > If i have a function that returns a named list with 2 (or more) elements, > then using 'vapply' retains the names of the elements: > .... > But if the function only returns one element, then the name "foo" is lost vapply _always simplifies_

Quote---------------- > If i have a function that returns a named list with 2 (or more) elements, > then using 'vapply' retains the names of the elements: > .... > But if the function only returns one element, then the name "foo" is lost vapply _always simplifies_ according to the documentation. In the first case (function return value contains more than one

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

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

Dear, I have noticed this problem while looking at the following question on Stackoverflow : http://stackoverflow.com/questions/42894213/s4-class-subset-inheritance-with-additional-arguments While going through callNextMethod, I've noticed the following odd behaviour: mc <- call("[",iris,2,"Species") mc[[1]] ## `[` is.primitive(`[`) ## [1] TRUE

On 11/18/19 10:45 AM, Martin Maechler wrote: >>>>>> Tomas Kalibera >>>>>> on Mon, 18 Nov 2019 09:36:14 +0100 writes: > > On 11/18/19 9:18 AM, Martin Maechler wrote: > >>>>>>> Henrik Bengtsson > >>>>>>> on Sun, 17 Nov 2019 14:31:07 -0800 writes: > >> > $ R --vanilla R

Originally, the distinguishing feature of "primitive" types was that they were enumerable and not parameterized on anything. Then we moved to arbitrary bit-width integers types to generalize things significantly (the right move IMO). Thus, integers were no longer technically primitive types, and their categorization in code has changed to reflect this. But that doesn't make *any

On 11/18/19 9:18 AM, Martin Maechler wrote: >>>>>> Henrik Bengtsson >>>>>> on Sun, 17 Nov 2019 14:31:07 -0800 writes: > > $ R --vanilla R version 3.6.1 (2019-07-05) -- "Action of > > the Toes" Copyright (C) 2019 The R Foundation for > > Statistical Computing Platform: x86_64-pc-linux-gnu > > (64-bit) ...

?typeof? is your friend here: > typeof(`[`) [1] "special" > typeof(mc[[1]]) [1] "symbol" > typeof(mc2[[1]]) [1] "special" so mc[[1]] is a symbol, and thus not a primitive. - Lukas > On 28 Mar 2017, at 14:46, Michael Lawrence <lawrence.michael at gene.com> wrote: > > There is a difference between the symbol and the function (primitive >

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.

The LLVM docs seem to indicate that integer types are considered primitive, however looking at the code I see `FirstDerivedTyID = IntegerTyID`, implying that integers are derived rather than primitive. Should the docs be updated? -------------- next part -------------- An HTML attachment was scrubbed... URL:

$ R --vanilla R version 3.6.1 (2019-07-05) -- "Action of the Toes" Copyright (C) 2019 The R Foundation for Statistical Computing Platform: x86_64-pc-linux-gnu (64-bit) ... > str(base::`+`) function (e1, e2) > plus <- structure(base::`+`, class = "plus") > str(plus) function (e1, e2) - attr(*, "class")= chr "plus" ## Hmm ... >