search for: g0c1

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:

...0a4bc000 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] "a" @7fa24be24428 09 CHARSXP g0c1 [MARK,REF(35010),gp=0x61] [ASCII] [cached] "b" @7fa24b806ec0 09 CHARSXP g0c1 [MARK,REF(35082),gp=0x61] [ASCII] [cached] "c" @7fa24bcc6af0 09 CHARSXP g0c1 [MARK,REF(35003),gp=...

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 02 LISTSXP g0c0 [] TAG: @100823078 01 SYMSXP g1c0 [MARK,LCK,gp=0x4000] "names" (has value) @104f17748 16 STRSXP g0c1 [NAM(2)] (len=1, tl=0) @10085c678 09 CHARSXP g...

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

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.

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

...1] "<0x55aa743e0bc0>" > x[1] <- 2Ltracemem[0x55aa743e0bc0 -> 0x55aa778f6ad0]: tracemem[0x55aa778f6ad0 -> 0x55aa778f6868]: [<-.data.frame [<- tracemem[0x55aa778f6868 -> 0x55aa778f5b48]: [<-.data.frame [<- > .Internal(inspect(x)) @55aa743e0bc0 19 VECSXP g0c1 [OBJ,MARK,NAM(7),TR,ATT] (len=1, tl=0) @55aa7440d420 13 INTSXP g0c0 [MARK,NAM(7)] 1 : 10 (compact) ATTRIB: @55aa743f9ea0 02 LISTSXP g0c0 [MARK] TAG: @55aa72ac98a0 01 SYMSXP g0c0 [MARK,NAM(7),LCK,gp=0x6000] "names" (has value) @55aa743e0fb0 16 STRSXP g0c1 [MARK,NAM(7)] (len=1, tl=0) @55aa7...

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?

...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 [] TAG: @7fb0c80043d0 01 SYMSXP g1c0 [MARK,LCK,gp=0x4000] "class" (has value) @7fb0c9fcbe90 16 STRSXP g0c1 [NAM(7)] (len=1, tl=0) @7fb0c80841a0 09 CHARSXP g1c1 [MARK,gp=0x61] [ASCII] [cached] "factor" TAG: @7fb0c8004050 01 SYMSXP g1c0 [MARK,NAM(7),LCK,gp=0x4000] "levels" (has value) @7fb0d1dd58c8 16 STRSXP g0c2 [MARK,NAM(7)] (len=2, tl=0) @7fb0c81bf4c0 09 CHARSXP...

...t; .Internal(inspect(a)) > @0x000000002384f530 14 REALSXP g0c3 [NAM(1),ATT] (len=3, tl=0) 1,2,3 > ATTRIB: > @0x0000000023864b58 02 LISTSXP g0c0 [] > TAG: @0x00000000044b1a90 01 SYMSXP g1c0 [MARK,LCK,gp=0x4000] "dim" > (has value) > @0x000000002384cb48 13 INTSXP g0c1 [NAM(7)] (len=2, tl=0) 1,3 > *This would cause a duplication, even though the function test does nothing.* > > test<-function(x) x1=x > > a=c(1,2,3) > > .Internal(inspect(a)) > @0x000000002384f260 14 REALSXP g0c3 [NAM(1)] (len=3, tl=0) 1,2,3 > > test(a) > >...

...l=1) @25c9628 00 NILSXP g0c0 [MARK,NAM(2)] @25c9628 00 NILSXP g0c0 [MARK,NAM(2)] @25c9628 00 NILSXP g0c0 [MARK,NAM(2)] @25c9628 00 NILSXP g0c0 [MARK,NAM(2)] @30b3370 02 LISTSXP g0c0 [] TAG: @2637870 01 SYMSXP g0c0 [MARK,NAM(2)] "x" @3569488 19 VECSXP g0c1 [NAM(1)] (len=1, tl=0) ## <--- NAM = 1 @35694e8 14 REALSXP g0c1 [NAM(2)] (len=1, tl=0) 1 ... > e$x [[1]] [1] 1 > .Internal(inspect(e)) @30b2498 04 ENVSXP g0c0 [NAM(1)] <0x30b2498> ENCLOS: @2600e98 04 ENVSXP g0c0 [MARK,NAM(2)] <R_EmptyEnv> HASHTAB: @2e41540...

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? @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]...

...can find out from >> >> > .Internal(inspect(eg)) >> @df70e48 25 S4SXP g0c0 [OBJ,NAM(2),gp=0x10,ATT] >> ATTRIB: >> @df70ef0 02 LISTSXP g0c0 [] >> TAG: @769258 01 SYMSXP g1c0 [MARK] "size" >> @c0f6db8 14 REALSXP g0c1 [NAM(2)] (len=1, tl=0) 4 >> TAG: @15b0228 01 SYMSXP g1c0 [MARK,NAM(2)] "id" >> @c0f6178 16 STRSXP g0c1 [NAM(2)] (len=1, tl=0) >> @12341c80 09 CHARSXP g0c2 [gp=0x20] "id_value" >> TAG: @607ce8 01 SYMSXP g1c0 [MARK,NAM(2),gp=0x...

I'm interested in the difference between these two intuitively equivalent sequences that produce different results (in R version 2.13.1 (2011-07-08) 32-bit). I think R's reference counting optimization is causing this difference in behavior. > a <- 1 > a+{a[1] <- 20} [1] 21 > a <- 1 > a[1] <- 1 > a+{a[1] <- 20} [1] 40 Is one of these the "correct"

...inspect(fc1)) > > @7fb0cae66408 13 INTSXP g0c2 [OBJ,NAM(2),ATT] (len=3, tl=0) 1,1,2 > > ATTRIB: > > @7fb0ce771868 02 LISTSXP g0c0 [] > > TAG: @7fb0c80043d0 01 SYMSXP g1c0 [MARK,LCK,gp=0x4000] "class" (has > > value) > > @7fb0c9fcbe90 16 STRSXP g0c1 [NAM(7)] (len=1, tl=0) > > @7fb0c80841a0 09 CHARSXP g1c1 [MARK,gp=0x61] [ASCII] [cached] > > "factor" > > TAG: @7fb0c8004050 01 SYMSXP g1c0 [MARK,NAM(7),LCK,gp=0x4000] > "levels" > > (has value) > > @7fb0d1dd58c8 16 STRSXP g0c2 [MAR...

...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" (has value) @15a65d8 19 VECSXP g0c1 [MARK] (len=1, tl=0) @10f3dd0 13 INTSXP g0c3 [OBJ,MARK,ATT] (len=8, tl=0) 1,15,1,15,15,... ATTRIB: @cc9618 02 LISTSXP g0c0 [MARK] TAG: @60dde0 01 SYMSXP g0c0 [MARK,NAM(2),LCK,gp=0x4000] *"srcfile" *(has value) *@cc97d8* 04 *ENVSXP* g0c0 [OBJ,MARK,NAM(2),ATT]...

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

> setClass("A", "integer") > isS4(new("A")) [1] TRUE > identical(isS4(new("A")), TRUE) [1] FALSE > sessionInfo() R Under development (unstable) (2012-10-04 r60876) Platform: x86_64-unknown-linux-gnu (64-bit) locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 [5]

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,

...th" @7f8992c41840 09 CHARSXP g0c2 [gp=0x61] [ASCII] [cached] "Sepal.Width" @7f8992c41808 09 CHARSXP g0c2 [gp=0x61,ATT] [ASCII] [cached] "Petal.Length" @7f898ba99f78 09 CHARSXP g0c2 [gp=0x61,ATT] [ASCII] [cached] "Petal.Width" @7f898b9a3468 09 CHARSXP g0c1 [gp=0x61,ATT] [ASCII] [cached] "Species" You can also look at R objects while in a debugger like gdb using the R_PV() function; see Writing R Extensions for details if this is something available to you. > ncol(boxMVariable)? - 5 > > nrow(boxMVariable)?? - 150 > > typ...