search for: g0c0

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

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 g0c0 [MARK,ATT] @604998 01 SYMSXP g0c0 [MARK,LCK,gp=0x5000] "{" (has value) ATTRIB: @cc9570 02 LISTSXP g0c0 [MARK] TAG: @60dd70 01 SYMSXP g0c0 [MARK,LCK,gp=0x4000] "srcref&quo...

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

...; > e$x[[1]] <- 2 > # tracemem[0x1148c1708 -> 0x11b2fc1b8]: Currently e$x marks values as immutable if they have any references by setting NAMED to 2. You can see this with > e <- new.env(parent = emptyenv()) > e$x <- list(1) > .Internal(inspect(e)) @30b2498 04 ENVSXP g0c0 [NAM(1)] <0x30b2498> ENCLOS: @2600e98 04 ENVSXP g0c0 [MARK,NAM(2)] <R_EmptyEnv> HASHTAB: @2e41540 19 VECSXP g0c7 [] (len=29, tl=1) @25c9628 00 NILSXP g0c0 [MARK,NAM(2)] @25c9628 00 NILSXP g0c0 [MARK,NAM(2)] @25c9628 00 NILSXP g0c0 [MARK,NAM(2)] @25c9628 00 NILS...

...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? @272f788 13 INTSXP g0c4 [NAM(1)] (len=10, tl=0) 1,2,3,4,5,... > z = data.frame() > .Internal(inspect(z)) # why NAM(2)? expected NAM(1) @24fc28c 19 VECSXP g0c0 [OBJ,NAM(2),ATT] (len=0, tl=0) ATTRIB: @24fc270 02 LISTSXP g0c0 [] TAG: @3f2120 01 SYMSXP g0c0 [MARK,gp=0x4000] "names" @24fc334 16 STRSXP g0c0 [] (len=0, tl=0) TAG: @3f2040 01 SYMSXP g0c0 [MARK,gp=0x4000] "row.names" @24fc318 13 INTSXP g0c0 [] (len=0, tl=0)...

...ehler: kann Vektor der Gr??e 14.9 GB nicht allozieren >> Sys.setenv(LANGUAGE="en") >> y <- c(0L, -2e9:2e9) > Error: cannot allocate vector of size 14.9 Gb >> y <- -1e9:4e9 >> .Internal(inspect(y)) > @0x00000000195a6808 14 REALSXP g0c0 [REF(65535)] -1000000000 : -294967296 (compact) >> .Machine$integer.max / 1e9 > [1] 2.147484 >> y <- -1e6:2.2e9 >> .Internal(inspect(y)) > @0x000000000a11a5d8 14 REALSXP g0c0 [REF(65535)] -1000000 : -2094967296 (compact) >> y <- -1e6:2e9...

...or. Using the wrapper avoided this issue. Here is my initial ALTREP integer vector: > fc0 <- factor(c("a", "a", "b")) > > y <- matter::as.matter(as.integer(fc0)) > y <- matter:::as.altrep(y) > > .Internal(inspect(y)) @7fb0ce78c0f0 13 INTSXP g0c0 [NAM(7)] matter vector (mode=3, len=3, mem=0) Here is what I get without a wrapper: > fc1 <- structure(y, class="factor", levels=levels(x)) > .Internal(inspect(fc1)) @7fb0cae66408 13 INTSXP g0c2 [OBJ,NAM(2),ATT] (len=3, tl=0) 1,1,2 ATTRIB: @7fb0ce771868 02 LISTSXP g0c0 []...

...ieren >> >> Sys.setenv(LANGUAGE="en") >> >> y <- c(0L, -2e9:2e9) >> > Error: cannot allocate vector of size 14.9 Gb >> >> y <- -1e9:4e9 >> >> .Internal(inspect(y)) >> > @0x00000000195a6808 14 REALSXP g0c0 [REF(65535)] -1000000000 : -294967296 (compact) >> >> .Machine$integer.max / 1e9 >> > [1] 2.147484 >> >> y <- -1e6:2.2e9 >> >> .Internal(inspect(y)) >> > @0x000000000a11a5d8 14 REALSXP g0c0 [REF(65535)] -1000000 : -2094967296...

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

...>> >> Sys.setenv(LANGUAGE="en") >> >> y <- c(0L, -2e9:2e9) >> > Error: cannot allocate vector of size 14.9 Gb >> >> y <- -1e9:4e9 >> >> .Internal(inspect(y)) >> > @0x00000000195a6808 14 REALSXP g0c0 [REF(65535)] -1000000000 : -294967296 (compact) >> >> .Machine$integer.max / 1e9 >> > [1] 2.147484 >> >> y <- -1e6:2.2e9 >> >> .Internal(inspect(y)) >> > @0x000000000a11a5d8 14 REALSXP g0c0 [REF(65535)] -1000000 : -20949...

I can only reproduce on Windows, but reliably (both 4.0.0 and 4.0.2): $> R --vanilla x <- c(0L, -2e9:2e9) # > Segmentation fault Tried to reproduce on Linux but the above worked as expected. Not an issue merely with the length of the vector; for example, x <- rep_len(1:10, 1e10) works, though the altrep vector must be long to reproduce: x <- c(0L, -1e9:1e9) #ok Segmentation

...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, len=3, > mem=0) My guess is that *matter:::as.altrep* function assigned the variable *y* to a local variable so that it increases the reference number. For example: *This would not cause a duplication* > > a=c(1,2,3) > > .Internal(inspect(a)) &gt...

...ed by R when an assignment operation implicitly introduces coercion for a large ALTREP object. For example, If I create a vector of length 10, the ALTREP coercion function seems to work fine. ``` > x <- 1:10 > y <- wrap_altrep(x) > .Internal(inspect(y)) @0x000000001f9271c0 13 INTSXP g0c0 [REF(2)] I am altrep > y[1] <- 1.0 Duplicating object Coercing object > .Internal(inspect(y)) @0x000000001f927c08 14 REALSXP g0c0 [REF(1)] I am altrep ``` However, if I create a vector of length 1024, R will give me a normal real-type vector ``` > x <- 1:1024 > y <- wrap_altre...

...; object.size(x) # 8000'000'000'000'048 bytes : 8000 TBytes -- ok, not really > 8000000000000048 bytes > > is.unsorted(x) # FALSE : i.e., R's *knows* it is sorted > [1] FALSE > > xs <- sort(x) # > > .Internal(inspect(x)) > @80255f8 14 REALSXP g0c0 [NAM(7)] 1 : 1000000000000000 (compact) > > > > > cx <- as.character(x) > > .Internal(inspect(cx)) > @80485d8 16 STRSXP g0c0 [NAM(1)] <deferred string conversion> > @80255f8 14 REALSXP g1c0 [MARK,NAM(7)] 1 : 1000000000000000 (compact) > > system...

...(a); > } and call it in R via > a=1:10 > > C_testFunc(a) > Error in C_testFunc(a) : cannot get STDVEC_DATAPTR from ALTREP object We can inspect the internal type and call ALTREP function to check if it is an ALTREP: > .Internal(inspect(a)) > @0x000000001b5a3310 13 INTSXP g0c0 [NAM(7)] 1 : 10 (compact) > > #This is a wrapper of ALTREP > > is.altrep(a) > [1] TRUE I've also defined an ALTREP type and it did not work either. I guess this might be a bug? Or did I miss something? 2. Wrapper objects in ALTREP If the duplicate function is defined to retu...

...ALTREP(x)) { > Rprintf("getting data 1\n"); > x = R_altrep_data1(x); > } > return(x); > } If calling R_altrep_data1 return the internal data directly, we will only see one message. following my last example > .Internal(inspect(so1)) > @0x0000000005e7fbb0 14 REALSXP g0c0 [MARK,NAM(7)] Share object of type > double > > .Internal(inspect(so2)) > @0x0000000005fc5ac0 14 REALSXP g0c0 [MARK,NAM(7)] wrapper > [srt=-2147483648,no_na=0] > @0x0000000005e7fbb0 14 REALSXP g0c0 [MARK,NAM(7)] Share object of type > double > > sm1=peekSharedMemory(...

> .Internal(inspect(1:10)) @300e4e8 13 INTSXP g0c0 [NAM(3)] 1 : 10 (compact) > .Internal(inspect(seq(1,10))) @3b6e1f8 13 INTSXP g0c4 [] (len=10, tl=0) 1,2,3,4,5,... > system.time(1:1e7) user system elapsed 0 0 0 > system.time(seq(1,1e7)) user system elapsed 0.05 0.00 0.04 It seems that result of functio...

...4.9 GB nicht allozieren > >> Sys.setenv(LANGUAGE="en") > >> y <- c(0L, -2e9:2e9) > > Error: cannot allocate vector of size 14.9 Gb > >> y <- -1e9:4e9 > >> .Internal(inspect(y)) > > @0x00000000195a6808 14 REALSXP g0c0 [REF(65535)] -1000000000 : -294967296 (compact) > >> .Machine$integer.max / 1e9 > > [1] 2.147484 > >> y <- -1e6:2.2e9 > >> .Internal(inspect(y)) > > @0x000000000a11a5d8 14 REALSXP g0c0 [REF(65535)] -1000000 : -2094967296 (compact) >...

...r??e 14.9 GB nicht allozieren > >> Sys.setenv(LANGUAGE="en") > >> y <- c(0L, -2e9:2e9) > > Error: cannot allocate vector of size 14.9 Gb > >> y <- -1e9:4e9 > >> .Internal(inspect(y)) > > @0x00000000195a6808 14 REALSXP g0c0 [REF(65535)] -1000000000 : -294967296 (compact) > >> .Machine$integer.max / 1e9 > > [1] 2.147484 > >> y <- -1e6:2.2e9 > >> .Internal(inspect(y)) > > @0x000000000a11a5d8 14 REALSXP g0c0 [REF(65535)] -1000000 : -2094967296 (compact) > &...

...gt; x <- 1:1e15 > object.size(x) # 8000'000'000'000'048 bytes : 8000 TBytes -- ok, not really 8000000000000048 bytes > is.unsorted(x) # FALSE : i.e., R's *knows* it is sorted [1] FALSE > xs <- sort(x) # > .Internal(inspect(x)) @80255f8 14 REALSXP g0c0 [NAM(7)] 1 : 1000000000000000 (compact) > > cx <- as.character(x) > .Internal(inspect(cx)) @80485d8 16 STRSXP g0c0 [NAM(1)] <deferred string conversion> @80255f8 14 REALSXP g1c0 [MARK,NAM(7)] 1 : 1000000000000000 (compact) > system.time( print(object.size(x)...