> The list gets copied, but do a and b, or does the new list point to
> the existing locations? The following test suggests that it's a deep
> copy.
>
> x <- 1:1e7
> z <- list(a = x)
>
> system.time(replicate(100, z$b <- 1L)) / 100
> # ~ 0.05s
> system.time(replicate(100, x[1e6 + 1L] <- 1L)) / 100
>> But does this?
>>
>> z <- as.list(x)
>> z$a <- 11
>
> Yes of course, as z is now of length 11. There is no provision in R to
> extend a vector except by creating a new one. (Well, there is at C level
> but I think it is not currently used.)
I guess a better example is
z <- list(a = 1:1e6, b
On 12/07/2012 18:20, Hadley Wickham wrote:
Read the help carefully as to what 'copy' means:
When an object is traced any copying of the object by the C
function ‘duplicate’ produces a message to standard output, as
does type coercion and copying when passing arguments to ‘.C’ o
> Read the help carefully as to what 'copy' means:
>
> When an object is traced any copying of the object by the C
> function ‘duplicate’ produces a message to standard output, as
> does type coercion and copying when passing arguments to ‘.C’ or
> ‘.Fortran’.
>
> If you want to
Read the help carefully as to what 'copy' means:
When an object is traced any copying of the object by the C
function ‘duplicate’ produces a message to standard output, as
does type coercion and copying when passing arguments to ‘.C’ or
‘.Fortran’.
If you want to understand w
Hadley Wickham rice.edu> writes:
> Why does x[5] <- 5 create a copy
That assigns 5 not 5L. x is being coerced from integer to double.
x[5] <- 5L doesn't copy.
> , when x[11] (which should be
> extending a vector does not) ? I can understand that maybe x[5] <- 5
> hasn't yet been optimised to
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] "<0x1058f8
