similar to: special handling of row.names

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

Hello, I?m experimenting with ALTREP and was wondering if there is a preferred way to create an ALTREP wrapper vector without using .Internal(wrap_meta(?)), which R CMD check doesn?t like since it uses an .Internal() function. I was trying to create a factor that used an ALTREP integer, but attempting to set the class and levels attributes always ended up duplicating and materializing the

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

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?

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?

Hi Lille, Is it possible you're looking for tracemem() or inspect() ? > x <- data.frame(z = 1:10)> tracemem(x)[1] "<0x55aa743e0bc0>" > x[1] <- 2Ltracemem[0x55aa743e0bc0 -> 0x55aa778f6ad0]: tracemem[0x55aa778f6ad0 -> 0x55aa778f6868]: [<-.data.frame [<- tracemem[0x55aa778f6868 -> 0x55aa778f5b48]: [<-.data.frame [<- >

Very interesting: > .Internal(inspect(k[i])) @10a4bc000 14 REALSXP g0c7 [ATT] (len=20000, tl=0) 1,2,3,4,1,... ATTRIB: @7fa24f07fa58 02 LISTSXP g0c0 [REF(1)] TAG: @7fa24b803e90 01 SYMSXP g0c0 [MARK,REF(5814),LCK,gp=0x6000] "names" (has value) @10a4e4000 16 STRSXP g0c7 [REF(1)] (len=20000, tl=0) @7fa24ba575c8 09 CHARSXP g0c1 [MARK,REF(35005),gp=0x61] [ASCII] [cached]

Specifically, the srcfile attribute of the srcref attribute of the two instances of the functions contain different environments, AFAICT. Environments are compared only by exact pointer, so this forces return FALSE. Snippets from .Internal(inspect(x)) and .Internal(inspect(y)): @cca008 03 CLOSXP g0c0 [MARK,NAM(2),ATT] FORMALS: @604b58 00 NILSXP g0c0 [MARK,NAM(2)] BODY: @cc9650 06 LANGSXP

On Fri, 5 Aug 2016, Winston Chang wrote: > 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

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 It seems that selecting an element of a factor will copy its levels (Ubuntu 13.04, R 3.0.2). Below is the output of a script that creates a factor with 10000 elements and then calls as.list() on it. The new object seems to use more than 700 MB, and inspection of the levels of the individual elements of the list suggest that they are distinct objects. Perhaps some performance gain could

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,

Hi Kylie, As an alternative in the short term, you could consider deriving from S4Vector's List class, implementing the getListElement() method to lazily create the objects. Michael On Tue, Jul 23, 2019 at 9:09 AM Bemis, Kylie <k.bemis at northeastern.edu> wrote: > > Hello, > > I was wondering if there were any plans for ALTREP lists (VECSXP)? > > It seems to me that

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

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 write barrier needs to see all mutations. So it would be best if Dataptr and Dataptr_or_null methods were not allowed to be defined. The default methods in

Hi, Again, sorry for the length of this post. Once I get my new office I will get a website set up on my work machine and will simply post a link to the log since I doubt many people are truly interested in these logs. To further analyze what is happening, I added my own routine in main.c called DEBUG_SET_NAMED and then redefined the SET_NAMED macro to use it and then rebuilt R. I

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

Can someone offer some advice on how to properly evaluate a SYMSXP from a .Call ? I have the following in R: variable xn, with an attribute "mu" which references the variable mu in the global environment. I know "references" is a loose term; mu was defined in this fashion as a way to implement deferred binding: foo <- function(x,mu) { attr(x,"mu") <-