Skip to content

Bugs due to naive copying of list elements

5 messages · Radford Neal, David Winsemius, Steven McKinney +2 more

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

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)

Similar bugs exist in eapply, rapply, and vapply.
#
On Mar 12, 2013, at 3:59 AM, Radford Neal wrote:

            
This is an example of lazy evaluation, right?
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.
[[1]]
[1] 3 4

[[2]]
[1] 5 6
[1] 9

#----------
[[1]]
[1] 2

[[2]]
[1] 2

[[3]]
[1] 2

[[1]]
[1] 2

[[2]]
[1] 2

[[3]]
[1] 2
[[1]]
[1] 99

[[2]]
[1] 99

[[3]]
[1] 99

  
    
#
Whereas
[[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
#
Thanks for the report. Fixed in r62220 on trunk, r62221 on
R-3-0-branch, and r62222 on R-2-15-branch.

Best,

luke
On Tue, 12 Mar 2013, Radford Neal wrote: