2

Post edit: Important Remark: The behavior here reported seems to be happening in RStudio only, and not from the R terminal.

My RStudio version is: 1.2.1511.

I am trying to understand when an object in R is subject to changes in place or when is it following copy-on-modify semantics.

Take this example from Hadley's Advanced R book.

In that example, Hadley is illustrating how an object in R can be modified in place. He talks of two cases: objects with single name binding and environments.

I tried his example with vector v but I do not get the address of vector v being preserved after changing one of its values.

After changing value 3 at position 3 of vector v the memory address of v changes from 0x5583a1461fb8 to 0x5583a2c5f608.

So my question is why? This seems to contradict Hadley's book example.

v <- c(1, 2, 3)
pryr::address(v)
#> [1] "0x5583a1461fb8"
lobstr::obj_addr(v)
#> [1] "0x5583a1461fb8"
v[[3]] <- 4
pryr::address(v)
#> [1] "0x5583a2c5f608"
lobstr::obj_addr(v)
#> [1] "0x5583a2c5f608"
sessionInfo()
#> R version 3.5.1 (2018-07-02)
#> Platform: x86_64-pc-linux-gnu (64-bit)
#> Running under: Arch Linux
#> 
#> Matrix products: default
#> BLAS: /usr/lib/libblas.so.3.8.0
#> LAPACK: /usr/lib/liblapack.so.3.8.0
#> 
#> locale:
#>  [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C              
#>  [3] LC_TIME=en_DK.utf8         LC_COLLATE=en_US.UTF-8    
#>  [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8   
#>  [7] LC_PAPER=en_US.UTF-8       LC_NAME=C                 
#>  [9] LC_ADDRESS=C               LC_TELEPHONE=C            
#> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C       
#> 
#> attached base packages:
#> [1] stats     graphics  grDevices utils     datasets  methods   base     
#> 
#> loaded via a namespace (and not attached):
#>  [1] Rcpp_1.0.1       codetools_0.2-15 digest_0.6.18    rprojroot_1.3-2 
#>  [5] backports_1.1.2  magrittr_1.5     evaluate_0.12    rlang_0.3.4     
#>  [9] stringi_1.4.3    pryr_0.1.4       rmarkdown_1.10   lobstr_1.0.1    
#> [13] tools_3.5.1      stringr_1.4.0    yaml_2.2.0       compiler_3.5.1  
#> [17] htmltools_0.3.6  knitr_1.20

P.S. I've used the pryr and lobstr packages to find the memory addresses. I've also tried using tracemem() but I got this error:

 Error in tracemem(m) : 
  R was not compiled with support for memory profiling
Ramiro Magno
  • 3,085
  • 15
  • 30
  • I've been wondering for a while now why I'm seeing `NAM(3)` on newly created objects like `v` in this example in R 3.5.2; I haven't gotten an explanation yet, but I would very much like one. – joran May 12 '19 at 21:33
  • 1
    What is `NAM(3)`? – Ramiro Magno May 12 '19 at 21:37
  • 2
    are you using rstudio ... do you also see this using R terminal? – user20650 May 12 '19 at 21:39
  • oopss.. @user20650! Indeed, using the R terminal only I do not see this... It does preserve the address. So it seems it is only with RStudio. Weird.. – Ramiro Magno May 12 '19 at 21:45
  • 1
    I know RStudio typically adjusts the named reference count to objects, I just for some reason thought that it adjusted it to 2 rather than 3. – joran May 12 '19 at 21:46
  • perhaps https://stackoverflow.com/questions/15559387/operator-in-rstudio-and-r – user20650 May 12 '19 at 21:47
  • 1
    @user20650 Yeah, exactly, only lately instead of seeing `NAM(2)` in RStudio, I've been seeing `NAM(3)` and I don't know why. I know they've been prepping for some big change away from the old reference counting scheme, but I just don't know if this is related. – joran May 12 '19 at 21:52

1 Answers1

2

As explained in this other question:

In place modification of matrices in R

The issue is that RStudio has a reference to v for its Environment pane. Therefore the v vector is no longer single name bound(?)... So when we change v, R needs to make copy of it.

fn <- function() {
  v <- c(1, 2, 3)
  print(pryr::address(v))
  print(lobstr::obj_addr(v))
  v[[3]] <- 4
  print(pryr::address(v))
  print(lobstr::obj_addr(v))
}

fn()
#> [1] "0x55e4acd1b538"
#> [1] "0x55e4acd1b538"
#> [1] "0x55e4acd1b538"
#> [1] "0x55e4acd1b538"
Ramiro Magno
  • 3,085
  • 15
  • 30