Hi, FWIW, seems to be a bug that a subrange of a list can not be named/properly referenced counted and therefore does not force a deepcopy to be made when a is later changed. The following works exactly as expected and the only difference is that it creates "b" from the entire list "a" before slicing it, and that forces proper reference counting and so R properly uses the appropriate deepcopy when a is changed. > a <- list(c(1,2), c(3,4), c(5,6))> a[[1]][1] 1 2 [[2]][1] 3 4 [[3]][1] 5 6 > b <- a> b <- b[2:3]> b[[1]][1] 3 4 [[2]][1] 5 6 > a[[2]][2] <- 9> b[[1]][1] 3 4 [[2]][1] 5 6 Kevin
> From: smckin...@bccrc.ca > To: r-devel@r-project.org > Date: Tue, 12 Mar 2013 11:40:27 -0700 > CC: radf...@cs.toronto.edu > Subject: Re: [Rd] Bugs due to naive copying of list elements > > Whereas > > > a <- list(c(1,2),c(3,4),c(5,6)) > > b <<- a[2:3] > > a[[2]][2] <- 9 > > b > [[1]] > [1] 3 4 > > [[2]] > [1] 5 6 > > > > > Examples such as this leave me in a cold sweat - where did I miss the > documentation describing > Radford's case? Can anyone point to the documentation that describes > Radford's outcome? > (It looks very lisp-like. Is it linked to R's origins in lisp?) > > I get the same outcome in R-2.11.1 so it is nothing new. I can only hope I > have not > set up such an effect in analysis scripts I've used to generate reproducible > publication output. > > Steven McKinney > > ________________________________________ > From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] On Behalf > Of David Winsemius [dwinsem...@comcast.net] > Sent: March 12, 2013 10:28 AM > To: Radford Neal > Cc: r-devel@r-project.org > Subject: Re: [Rd] Bugs due to naive copying of list elements > > On Mar 12, 2013, at 3:59 AM, Radford Neal wrote: > > > Several bugs are present in R-2.15.3 and R-alpha due to > > naive copying of list elements. > > > > The bug below is due to naive copying in subset.c (with > > similar bugs for matrices and arrays): > > > > a<-list(c(1,2),c(3,4),c(5,6)) > > b<-a[2:3] > > a[[2]][2]<-9 > > print(b[[1]][2]) > > This is an example of lazy evaluation, right? > > > > > Naive copying in mapply.c leads to the following bug: > > > > X<-1+1 > > f<-function(a,b) X > > A<-mapply(f,c(1,2,3),c(4,5,6),SIMPLIFY=FALSE) > > print(A) > > X[1]<-99 > > print(A) > > > > Is this a bug in mapply()? or in print()? I thought 'print' should evaluate > its argument and "force" the promise to be executed. Or does it just return > the same promise as was passed to it? Compare: > > X<-1+1 > f<-function(a,b) X > A<-mapply(f,c(1,2,3),c(4,5,6),SIMPLIFY=FALSE) > print(A); str(A) > X[1]<-99 > print(A) > > Could someone could comment on what 'force' actually does. I am unclear why > force(A) in the code above in the pace of str(A) did not have the effect I > expected, whereas str(b) or str(A) did have that effect. > > > a<-list(c(1,2),c(3,4),c(5,6)) > > b<-a[2:3]; force(b) > [[1]] > [1] 3 4 > > [[2]] > [1] 5 6 > > > a[[2]][2]<-9 > > print(b[[1]][2]) > [1] 9 > > #---------- > > X<-1+1 > > f<-function(a,b) X > > A<-mapply(f,c(1,2,3),c(4,5,6),SIMPLIFY=FALSE) > > print(A); force(A) > [[1]] > [1] 2 > > [[2]] > [1] 2 > > [[3]] > [1] 2 > > [[1]] > [1] 2 > > [[2]] > [1] 2 > > [[3]] > [1] 2 > > > X[1]<-99 > > print(A) > [[1]] > [1] 99 > > [[2]] > [1] 99 > > [[3]] > [1] 99 > > > > Similar bugs exist in eapply, rapply, and vapply. > > > > -- > David Winsemius > Alameda, CA, USA > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
