Displaying 20 results from an estimated 300 matches similar to: "suggest that as.double( something double ) not make a copy"
2016 Aug 05
2
Extra copies of objects in environments when using $ operator?
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
2020 Jan 09
6
Get memory address of an R data frame
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.
2020 Jul 22
3
Invisible names problem
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:
2006 Jul 31
5
use tracemem to dump content in function read/write
Hi Expert
I want to use dtrace to monitor the content change of one file. I made following scripts,
#!/usr/sbin/dtrace -s
inline int MYPID = $1;
syscall::write:entry
/pid == MYPID/
{
tracemem(arg1, arg2);
printf("\n");
}
It always has an following error
bash-3.00$ sudo dumpFIFO.dtrace 3836
dtrace: failed to compile script ./dumpFIFO.dtrace: line 19: tracemem( ) argument #2
2010 Nov 23
1
Possibility for memory improvement: x <- as.vector(x) always(?) duplicates
Hi,
I've noticed that as.vector() always allocates a new object, e.g.
> x <- 1:10;
> x <- as.vector(x);
> tracemem(x);
[1] "<0x0000000005622db8"
> x <- as.vector(x);
tracemem[0x0000000005622db8 -> 0x0000000005622ec0]: as.vector
> x <- as.vector(x);
tracemem[0x0000000005622ec0 -> 0x0000000005622f18]: as.vector
> x <- as.vector(x);
2016 Apr 05
1
Assignment operator and deep copy for calling C functions
Hi All,
i have a problem in understanding what the assignment operator '<-' really is doing.
If i create two numeric arrays in R and copy one into the other with '<-' and
afterwards change one array by calling a C function, both arrays are changed!
The problem I am facing can easily be seen in the following example:
(The following R code and the C function is attached and
2008 Feb 26
11
Is there way to trace memory in the dtrace ?
N_conreq:entry {
self->x=1;
calledaddr=(struct xaddrf *)arg3;
callingaddr=(struct xaddrf *)arg4;
trace(calledaddr->link_id);
tracemem(calledaddr->DTE_MAC.lsap_add, 80);
trace(callingaddr->link_id);
tracemem(callingaddr->DTE_MAC.lsap_add, 80);
}
0 -> N_conreq 255
2012 Jul 12
2
Understanding tracemem
Hi all,
I've been trying to get a better handle on what manipulations lead R
to duplicate a vector, creating small experiments and using tracemem
to observe what happens (all in 2.15.1). That's lead me to a few
questions, illustrated using the snippet below.
x <- 1:10
tracemem(x)
# [1] "<0x1058f8238>"
x[5] <- 5
# tracemem[0x1058f8238 -> 0x105994ab0]:
x[11] <-
2010 Sep 01
6
Why is vector assignment in R recreates the entire vector ?
Hello all,
A friend recently brought to my attention that vector assignment actually
recreates the entire vector on which the assignment is performed.
So for example, the code:
x[10]<- NA # The original call (short version)
Is really doing this:
x<- replace(x, list=10, values=NA) # The original call (long version)
# assigning a whole new vector to x
Which is actually doing this:
x<-
2012 Jan 17
1
names<- appears to copy 3 times?
Hi,
$ R --vanilla
R version 2.14.1 (2011-12-22)
Platform: i686-pc-linux-gnu (32-bit)
> DF = data.frame(a=1:3,b=4:6)
> DF
a b
1 1 4
2 2 5
3 3 6
> tracemem(DF)
[1] "<0x8898098>"
> names(DF)[2]="B"
tracemem[0x8898098 -> 0x8763e18]:
tracemem[0x8763e18 -> 0x8766be8]:
tracemem[0x8766be8 -> 0x8766b68]:
> DF
a B
1 1 4
2 2 5
3 3 6
>
Are those 3
2010 Nov 12
1
SEXPs and slots
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?
2006 Jun 29
2
tracemem() not exactly what I had in mind
I was trying to use tracemem to look at mblk contents. First, I tried to use
mblk->b_wptr - mblk->b_rptr as the size, and was told that it had to be a
constant. Foo. (RFE #1).
Then, I tried to use 8 as the size, and kept getting decimal numbers printed.
Stumbled on #pragma D option rawbytes=true (is the =true necessary, btw?) and
that didn''t help.
Then, in desperation, I
2012 Apr 14
1
deep copy?
Is putting a variable into a list a deep copy (and is tracemem the
correct way to confirm)?
warmstrong at krypton:~/dvl/R.packages$ R
> x <- rnorm(1000)
> tracemem(x)
[1] "<0x3214c90>"
> x.list <- list(x.in.list=x)
tracemem[0x3214c90 -> 0x2af0a20]:
>
Is it possible to put a variable into a list without causing a deep
copy (i.e. if you _really_ want the
2019 Jul 17
2
ALTREP wrappers and factors
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
2016 Aug 05
0
Extra copies of objects in environments when using $ operator?
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
2020 Jan 09
0
Get memory address of an R data frame
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 [<-
>
2011 Jul 25
2
Best practices for writing R functions (really copying)
Gabriel Becker writes:
AFAIK R does not automatically copy function arguments. R actually tries
very hard to avoid copying while maintaining "pass by value" functionality.
... R only copies data when you modify an object, not
when you simply pass it to a function.
This is a bit misleading. R tries to avoid copying by maintaining a
count of how many references there are to an
2010 Nov 23
1
Slow update(insert) on Data.frame
Hi
When I try to update an number in a large data.frame by its pos It's really
slow it take almost a sec to do this and I wonder why and if where is any
faster way to update a number in a data.frame
ive tried
DF$col[POS]<-number
DF[xPOS,yPOS]<-number
Thx
//Joel
--
View this message in context: http://r.789695.n4.nabble.com/Slow-update-insert-on-Data-frame-tp3055707p3055707.html
2011 Nov 24
1
Confused about NAMED
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?
2011 Sep 30
1
Language definition question - order of argument side effects
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"