similar to: ALTREP wrappers and factors

Hi Jiefei and Kylie, Great to see people engaging with the ALTREP framework and identifying places we may need more tooling. Comments inline. On Thu, Jul 18, 2019 at 12:22 PM King Jiefei <szwjf08 at gmail.com> wrote: > > If that is the case and you are 100% sure the reference number should be 1 > for your variable *y*, my solution is to call *SET_NAMED *in C++ to reset > the

Hi Kylie, For your question, I don't think a wrapper can completely solve your problem. The duplication occurs since your variable y has more than 1 reference number( Please see highlighted), so even you have a wrapper, any changes on the value of the wrapper still can trigger the duplication. > .Internal(inspect(y)) > @7fb0ce78c0f0 13 INTSXP g0c0 *[NAM(7)]* matter vector (mode=3,

Hello, I've created this class: setClass("example", representation ( size = "numeric", id = "character" ) ) Suppose I create a new instance of this class: > x <- new("example", 4, "id_value") This creates an S4 object with two slots. Am I correct in thinking that slots are "filled" by SEXPs?

I ran into strange behavior when removing names. Two ways of removing names: i <- rep(1:4, length.out=20000) k <- c(a=1, b=2, c=3, d=4) x1 <- unname(k[i]) x2 <- k[i] x2 <- unname(x2) Are they identical? identical(x1,x2) # TRUE but no identical(serialize(x1,NULL),serialize(x2,NULL)) # FALSE But problem is with serialization type 3, cause:

Reading "R Internals" made me believe that R_UnboundValue was a placeholder that would be skipped over in variable lookup. viz. the section of R Internals "Hash tables" says "items are not actually deleted but have their value set to R_UnboundValue.", which seems to align with what I read in envir.c. So, I reasoned, if I have a function that returns R_UnboundValue,

Hi, I expected NAMED to be 1 in all these three cases. It is for one of them, but not the other two? > R --vanilla R version 2.14.0 (2011-10-31) Platform: i386-pc-mingw32/i386 (32-bit) > x = 1L > .Internal(inspect(x)) # why NAM(2)? expected NAM(1) @2514aa0 13 INTSXP g0c1 [NAM(2)] (len=1, tl=0) 1 > y = 1:10 > .Internal(inspect(y)) # NAM(1) as expected but why different to x?

Hello, I would like for my C function to be able to manipulate some values stored in an R data frame. To achieve this, a need the (real) memory address where the R data frame stores its data (hopefully in a contiguous way). Then, from R, I call the C function and passing this memory address as a parameter. The question: how can we get the memory address of the R data frame? Thank you! L.

Hi I'm trying to implement something similar to the following R snippet using C. I seem to have hit the wall on accessing class slots using C. library(fPortfolio) lppData <- 100 * LPP2005.RET[, 1:6] ewSpec <- portfolioSpec() nAssets <- ncol(lppData) setWeights(ewSpec) <- rep(1/nAssets, times = nAssets) ewPortfolio <- feasiblePortfolio( data = lppData, spec = ewSpec,

Hello, I think there is an inconsistency in the handling of the compact form of the row.names attributes. When n is the number of rows of a data.frame, the compact form is c(NA_integer_,-n), as in: > d <- data.frame(x=1:10) > .Internal(inspect(d)) @104f174a8 19 VECSXP g0c1 [OBJ,NAM(2),ATT] (len=1, tl=0) @103a7dc60 13 INTSXP g0c4 [] (len=10, tl=0) 1,2,3,4,5,... ATTRIB: @104959380

Hello, Since people have whisperred about Rcpp, I'd like to play too. > On 11/15/2010 07:45 AM, Patrick Leyshock wrote: >> Very helpful, thank you. >> >> A couple other questions, please: >> >> 1. I've got a function written in C, named "my_c_function". In my R >> code I call this function, passing to it an INTSXP and a STRSXP, >>

My understanding is that R will not make copies of lists if there is only one reference to the object. However, I've encountered a case where R does make copies, even though (I think) there should be only one reference to the object. I hope that someone could shed some light on why this is happening. I'll start with a simple example. Below, x is a list with one element, and changing that

I'm confused by this: > identical(function() {}, function() {}) [1] FALSE Yet, after loading the Matrix package (which redefines det), the following is checked (in library.checkConflicts): > identical(get("det", baseenv()), get("det", asNamespace("Matrix")), ignore.environment=T) [1] TRUE I've looked at the code in identical.c and for closures it

Hello, I was wondering if there were any plans for ALTREP lists (VECSXP)? It seems to me that they could be supported in a similar way to how ALTSTRING works, with Elt() and Set_elt() methods, or would there be some problems with that I?m not seeing due to lists not being atomic vectors? I was taking an approach of converting each list element (of a file-based list data structure) to an ALTREP

Hi Kylie, Is it a list with only numerics in it? (I only see REALSXPs there, but obviously inspect isn't showing all of them). If so, you could load it up into one big vector and then also keep partitioning information around. Bioconductor does this (see ?IRanges::CompressedList ). The potential benefit here being that the underlying large vector could then be a big out-of-memory altrep. How

I can work on this. Thanks Luke. ~G On Wed, Jul 24, 2019 at 8:25 AM Tierney, Luke <luke-tierney at uiowa.edu> wrote: > If one of you wanted to try to create a patch to support ALTREP > generic vectors here are some notes: > > The main challenge I am aware of (there might be others): Allowing > DATAPTR to return a writable pointer would be too dangerous because > the GC

On Mon, 21 Jan 2019, Martin Maechler wrote: >>>>>> Travers Ching >>>>>> on Tue, 15 Jan 2019 12:50:45 -0800 writes: > > > I have a toy alt-rep string package that generates > > randomly seeded strings. example: library(altstringisode) > > x <- altrandomStrings(1e8) head(x) [1] > >

I have a toy alt-rep string package that generates randomly seeded strings. example: library(altstringisode) x <- altrandomStrings(1e8) head(x) [1] "2PN0bdwPY7CA8M06zVKEkhHgZVgtV1" "5PN2qmWqBlQ9wQj99nsQzldVI5ZuGX" ... etc object.size(1e8) Object.size will call the set_altstring_Elt_method for every single element, materializing (slowly) every element of the vector. This

Hello All, I tried the sample code from the help. Although '{' is assigned to 'do', the call syntaxes for 'do' and '{' are not the same ('do' has ','s, but '{' has line breaks). I guess there is a difference in parsing the code block of 'do' and the code block of '{'. Could you please let me know some internal details so that

I've been playing with passing arguments to .C(), and found that replacing as.double(x) with if(is.double(x)) x else as.double(x) saves time and avoids one copy, in the case that x is already double. I suggest modifying as.double to avoid the extra copy and just return x, when x is already double. Similarly for as.integer, etc. [[alternative HTML version deleted]]

On 1/22/19 6:17 PM, Kevin Ushey wrote: > I think that object.size() is most commonly used to answer the question, > "what R objects are consuming the most memory currently in my R session?" > and for that reason I think returning the size of the internal > representations of objects (for e.g. ALTREP objects; unevaluated promises) > is the right default behavior. I