similar to: length(unclass(x)) without unclass(x)?

> Henrik Bengtsson: > > I'm looking for a way to get the length of an object 'x' as given by > base data type without dispatching on class. The performance improvement you're looking for is implemented in the latest version of pqR (pqR-2016-10-24, see pqR-project.org), along with corresponding improvements in several other circumstances where unclass(x) does not

On 09/05/2018 11:18 AM, I?aki Ucar wrote: > The bottomline here is that one can always call a base method, > inexpensively and without modifying the object, in, let's say, > *formal* OOP languages. In R, this is not possible in general. It > would be possible if there was always a foo.default, but primitives > use internal dispatch. > > I was wondering whether it would be

The solution below introduces a dependency on data.table, but otherwise it does what you need: --- # special method for Foo objects length.Foo <- function(x) { length(unlist(x, recursive = TRUE, use.names = FALSE)) } # an instance of a Foo object x <- structure(list(a = 1, b = list(b1 = 1, b2 = 2)), class = "Foo") # its length stopifnot(length(x) == 3L) # get its length as

On 08/24/2018 07:55 PM, Henrik Bengtsson wrote: > Is there a low-level function that returns the length of an object 'x' > - the length that for instance .subset(x) and .subset2(x) see? An > obvious candidate would be to use: > > .length <- function(x) length(unclass(x)) > > However, I'm concerned that calling unclass(x) may trigger an > expensive copy

Hi Tomas, On 09/03/2018 11:49 AM, Tomas Kalibera wrote: > Please don't do this to get the underlying vector length (or to achieve > anything else). Setting/deleting attributes of an R object without > checking the reference count violates R semantics, which in turn can > have unpredictable results on R programs (essentially undebuggable > segfaults now or more likely later

The bottomline here is that one can always call a base method, inexpensively and without modifying the object, in, let's say, *formal* OOP languages. In R, this is not possible in general. It would be possible if there was always a foo.default, but primitives use internal dispatch. I was wondering whether it would be possible to provide a super(x, n) function which simply causes the

Is there a low-level function that returns the length of an object 'x' - the length that for instance .subset(x) and .subset2(x) see? An obvious candidate would be to use: .length <- function(x) length(unclass(x)) However, I'm concerned that calling unclass(x) may trigger an expensive copy internally in some cases. Is that concern unfounded? Thxs, Henrik

Please don't do this to get the underlying vector length (or to achieve anything else). Setting/deleting attributes of an R object without checking the reference count violates R semantics, which in turn can have unpredictable results on R programs (essentially undebuggable segfaults now or more likely later when new optimizations or features are added to the language). Setting attributes

Regarding the discussion of getting length(unclass(x)) without an unclassed version of x being created... There are already no copies done for length(unclass(x)) in pqR (current version of 2017-06-09 at pqR-project.org, as well as the soon-to-be-release new version). This is part of a more general facility for avoiding copies from unclass in other circumstances as well - eg,

Hi, there was a memory improvement done in R going from R 3.3.3 to R 3.4.0 when it comes to comparing an integer 'x' an double 'y' (either may be scalar or vector). For example, in R 3.3.3, I get: > getRversion() [1] '3.3.3' > x <- integer(1000) > y <- double(1000) > profmem::profmem(z <- (x < y)) Rprofmem memory profiling of: z <- (x < y)

More generally, I think one of the issues is that R is not yet able to decrement a reference count (or mark a 'shared' data object as 'unshared' after it knows only one binding to it exists). This means passing variables to R closures will mark that object as shared: x <- list() .Internal(inspect(x)) # NAM(1) identity(x) .Internal(inspect(x)) # NAM(3) I think

>>>>> Henrik Bengtsson <henrik.bengtsson at gmail.com> >>>>> on Thu, 25 Jan 2018 09:30:42 -0800 writes: > Just following up on this old thread since matrixStats 0.53.0 is now > out, which supports this use case: >> x <- rep(TRUE, times = 2^31) >> y <- sum(x) >> y > [1] NA > Warning message:

I'd expect that a lot of the performance overhead could be eliminated by simply improving the underlying code. IMHO, we should ignore it in deciding the API that we want here. On Fri, Sep 23, 2016 at 10:54 AM, Henrik Bengtsson <henrik.bengtsson at gmail.com> wrote: > I'd vote for it to stay. It could of course suprise someone who'd > expect c(list(a=1), b=2, use.names =

Just following up on this old thread since matrixStats 0.53.0 is now out, which supports this use case: > x <- rep(TRUE, times = 2^31) > y <- sum(x) > y [1] NA Warning message: In sum(x) : integer overflow - use sum(as.numeric(.)) > y <- matrixStats::sum2(x, mode = "double") > y [1] 2147483648 > str(y) num 2.15e+09 No coercion is taking place, so the

>>>>> Herv? Pag?s <hpages at fredhutch.org> >>>>> on Tue, 30 Jan 2018 13:30:18 -0800 writes: > Hi Martin, Henrik, > Thanks for the follow up. > @Martin: I vote for 2) without *any* hesitation :-) > (and uniformity could be restored at some point in the > future by having prod(), rowSums(), colSums(), and others >

I'd vote for it to stay. It could of course suprise someone who'd expect c(list(a=1), b=2, use.names = FALSE) to generate list(a=1, b=2, use.names=FALSE). On the upside, is the performance gain from using use.names=FALSE. Below benchmarks show that the combining of the names attributes themselves takes ~20-25 times longer than the combining of the integers themselves. Also, at no

Hi Martin, Henrik, Thanks for the follow up. @Martin: I vote for 2) without *any* hesitation :-) (and uniformity could be restored at some point in the future by having prod(), rowSums(), colSums(), and others align with the behavior of length() and sum()) Cheers, H. On 01/27/2018 03:06 AM, Martin Maechler wrote: >>>>>> Henrik Bengtsson <henrik.bengtsson at gmail.com>

>From comments in http://stackoverflow.com/questions/24815572/why-does-function-c-accept-an-undocumented-argument/24815653 : The code of c() and unlist() was formerly shared but has been (long time passing) separated. From July 30, 1998, is where do_c got split into do_c and do_unlist. With the implementation of 'c.Date' in R devel r71350, an argument named 'use.names' is

Dear R-devel, I periodically stumble on the same challenges when working with objects with bracket S3 methods, and their length and names counterparts. I make the distinction between what I call S3 subsetting using `[` and `[[` and low level subsetting using `.subset()` and `.subset2()`. When working with low level subsetting one has to be extremely careful, because `length()`, `names()`, and

I second this feature request (it's understandable that this and possibly other parts of the code was left behind / forgotten after the introduction of long vector). I think mean() avoids full copies, so in the meanwhile, you can work around this limitation using: countTRUE <- function(x, na.rm = FALSE) { nx <- length(x) if (nx < .Machine$integer.max) return(sum(x, na.rm =