similar to: True length - length(unclass(x)) - without having to call unclass()?

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

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

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

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

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

Suharto, If you're interested in performance with subscripting, you might want to look at pqR (pqR-project.org). It has some substantial performance improvements for subscripting over R Core versions. This is especially true for the current development version of pqR (probably leading to a new release in about a month). You can look at a somewhat-stable snapshot of recent pqR development

I have rewritten the R parser in the new version of pqR that I recently released (pqR-2015-09-14, at pqR-project.org). The new version of the parser is much cleaner, is faster (sometimes quite substantially faster), has a better interface to the read-eval-print loop, and provides a better basis for future extensions. The deparser has also been substantially revised in pqR, and is better

> From: Tomas Kalibera <tomas.kalibera at gmail.com> > > Thanks for the report, I am working on a patch that will address this. > > I confirm there is a lot of potential for speedup. On my system, > > 'N=200000; x <- substring(paste(rep("A", N), collapse=""), 1:N, 1:N)' > > spends 96% time in checking if the string is ascii and 3%

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

41;309;0c> Why does debug() enter Browse[3] here at all, and why does it happen the > first time and not the second? This seems unexpected to me, and has > undesirable effects for ESS users (that I reported here - > https://stat.ethz.ch/pipermail/ess-help/2013-June/009154.html - but just > realized my post to r-devel didn't make it through when I tried to report > it back

I'm looking for a way to get the length of an object 'x' as given by base data type without dispatching on class. Something analogous to how .subset()/.subset2(), e.g. a .length() function. I know that I can do length(unclass(x)), but that will trigger the creation of a new object unclass(x) which I want to avoid because 'x' might be very large. Here's a dummy example

>>>>> Harvey Smith >>>>> on Wed, 1 May 2019 03:20:55 -0400 writes: > Inside of the anyNA() function, it will use the legacy any(is.na()) code if > x is an OBJECT(). If x is a vector of POSIXct, it will be an OBJECT(), but > it is also TYPEOF(x) == REALSXP. Therefore, it will skip the faster > ITERATE_BY_REGION, which is typically 5x

> From: "Cohn, Robert S" <robert.s.cohn at intel.com> > > I am using R to multiply some large (30k x 30k double) matrices on a > 64 core machine (xeon phi). I added some timers to > src/main/array.c to see where the time is going. All of the time is > being spent in the matprod function, most of that time is spent in > dgemm. 15 seconds is in matprod in

Hugh, (Note I speak for myself only and not for R-core) Thanks for looking into this. I think it's great to have community members that are interested in contributing to R and helping it continue to get better. And I think, and my local experiments bear out, that using anyNA as a fastpass condition does allow us to get a significant speedup over what's in there now. To do so, though, I

Dmitriy Selivanov (selivanov.dmitriy at gmail.com) wrote: > Consider following example: > > a = matrix(1:2, nrow = 2, dimnames = list(c("row1", "row2"), c("col1"))) > a[1, ] > # 1 > > It returns *unnamed* vector `1` where I would expect named vector. In fact > it returns named vector when number of columns is > 1. > Same issue applicable

On 14/07/2015 6:08 PM, Radford Neal wrote: > In testing pqR on Solaris SPARC systems, I have found two bugs that > are also present in recent R Core versions. You can see the bugs and > fixes at the following URLs: > > https://github.com/radfordneal/pqR/commit/739a4960a4d8f3a3b20cfc311518369576689f37 Thanks for the report. Just one followup on this one: There are two sections

On Tue, Jul 14, 2015 at 07:52:56PM -0400, Duncan Murdoch wrote: > On 14/07/2015 6:08 PM, Radford Neal wrote: > > In testing pqR on Solaris SPARC systems, I have found two bugs that > > are also present in recent R Core versions. You can see the bugs and > > fixes at the following URLs: > > > >