search for: refclasses

I'm using refClass for a complex multi-directional tree structure with possibly 100,000s of nodes. The refClass design is very impressive and I'd love to use it, but I've found that the size of refClass instances are very large and creation time is slow. For example, below is a RefClass and normal S4 class. The RefClass requires about 4KB per instance vs 500B for the S4 class --

Hi, does anyone know if it is possible to construct sets of S4 objects? It seems the constructor set does not like it: Error in as.vector(x, "character") : cannot coerce type 'environment' to vector of type 'character' Regards Johnny [[alternative HTML version deleted]]

Hi, does anyone know if it is possible to construct sets of S4 objects? It seems the constructor set does not like it: Error in as.vector(x, "character") : cannot coerce type 'environment' to vector of type 'character' Regards Johnny PS: by the way, does anyone know where I can find some examples using the cset class from the "sets" package, beside the

Hello Everyone! Here are a couple of thought/questions on refClasses integration in R core functionality. First, coexistence with S4: > X <- setRefClass("classX", fields = c("a", "b"), + representation = list(c = "character")) > x <- X$new() > x at c <- "sss" > x An object of c...

Greetings, I am trying to use Reference Class methods in Snowfall, using R 2.12.1 on Ubuntu Natty. Using then directly seems to work (stanza 2 below), but using them indirectly does not (stanza 3 below). I get an "attempt to apply non-function" error. In addition to exporting the instance of the object I created to the Snowfall slaves, I also made several attempts to export the

Hi all, I've constructed the following function to test whether or not an object was created from a reference class: isRefClassObject <- function(x) isS4(x) && is.environment(attr(x,'.xData')) && exists('.refClassDef',attr(x,'.xData')) but I'm unsure if it's a complete test or if there's a better way to test. Regardless, It would be

Hi Gabe, On 09/29/2015 02:51 PM, Gabriel Becker wrote: > Herve, > > The problem then would be that for A a refClass whose fields take up N > bytes (in the sense that you mean), if we do > > B <- A > > A and B would look like the BOTH take up N bytes, for a total of 2N, > whereas AFAIK R would only be using ~ N + 2*56 bytes, right? Yes, but that's still a *much*

When a reference class method is accessed with .self$x, it has different behavior from .self[['x']]. The former copies the function to the object's environment (with some attributes attached), and the latter just return NULL (unless it has already been accessed once with .self$x). Is this how it's supposed to work? Here's an example that illustrates:

Could of requests: 1) Is there any example or writeup on the difficulties of extending reference classes across packages? Just so I can fully understand the issues. 2) In what sorts of situations does the performance of reference classes cause problems? Sure, it's an order of magnitude slower than constructing a simple environment, but those timings are in microseconds, so one would need a

Hi, Currently object.size() is not very useful on environments as it always returns 56 bytes, no matter how big the environment is: env1 <- new.env() object.size(env1) # 56 bytes env2 <- new.env(hash=TRUE, size=75000000L) object.size(env2) # 56 bytes env3 <- list2env(list(a=runif(25000000), L=LETTERS)) object.size(env3) # 56 bytes This makes it pretty useless on

I was wondering: are the downstream dependencies of a package rebuilt when a package is updated on CRAN? (I'm referring to the binary packages, of course.) The reason I ask is because there are cases where this can cause problems. Suppose that when pkgB is built, it calls pkgA::makeClosure(), which returns a closure that refers to a function in pkgA. Suppose this code is in pkgA 1.0:

...#39;s an order of magnitude slower than > constructing a simple environment, but those timings are in > microseconds, so one would need a thousand objects before it started > to be noticeable. Some motivating use cases would help. It's a bit of a pathological case, but the switch from RefClasses to R6 made a noticeable performance improvement in shiny. It's hard to quantify the impact on an app, but the impact on the underlying reactive implementation was quite profound: http://rpubs.com/wch/27260 vs http://rpubs.com/wch/27264 R6 also includes a vignette with detailed benchmarking: h...

Herve, The problem then would be that for A a refClass whose fields take up N bytes (in the sense that you mean), if we do B <- A A and B would look like the BOTH take up N bytes, for a total of 2N, whereas AFAIK R would only be using ~ N + 2*56 bytes, right? ~G On Tue, Sep 29, 2015 at 2:42 PM, Herv? Pag?s <hpages at fredhutch.org> wrote: > Hi, > > Currently object.size()

Hello, I am somewhat new to R programming and a novice C++ programmer. I'd like to know if I should use setRefClass() to manage objects, functions, and data in a very large program I am attempting to code. See: http://stat.ethz.ch/R-manual/R-devel/library/methods/html/refClass.html I like the referential class structure that C++ provides and R seems to provides via setRefClass(). Mainly

Dear list, is there a shortcut-function to check whether a class is a Reference Class or not? There's something like this for S4 classes ('isS4(object)'), but I couldn't find anything regarding Ref Classes. Currently, I'm doing it this way, which is a bit clumsy: A <- setRefClass("A", fields=list(X="numeric")) a <- A$new() isRefClass <-

Dear All, In a project I've been working on we've been using Reference Classes and grid extensively. However, something that I have come across is that when using the import() method on refclass objects, it does not work as expected with grid grobs and viewports. I have prepared test cases that illustrate the point but the general idea is that importing appears to work fine for

>>>>> Michael Lawrence <lawrence.michael at gene.com> >>>>> on Mon, 26 Jan 2015 05:12:55 -0800 writes: > A isNamespaceLoaded() function would be a useful thing to > have in general if we are interested in readable code. An > efficient implementation would be just a bonus. Good point (readability), and thank you for the support! Note