Is this expected behavior?> z <- 1:5 > z[1] <<- 0Error in z[1] <<- 0 : object "z" not found The documentation seems to suggest that z will be found in the global environment and modified accordingly. Best, Hsiu-Khuern.
On 2/07/2009, at 12:20 PM, Hsiu-Khuern Tang wrote:> Is this expected behavior? > >> z <- 1:5 >> z[1] <<- 0 > Error in z[1] <<- 0 : object "z" not found > > The documentation seems to suggest that z will be found in the global > environment and modified accordingly.I would agree that the documentation would *suggest* that, but it doesn't explicitly say it, and no more it should, since the "[<<-" operator does not exist. Unlike the "[<-" operator which does exist. Moreover there is little reason for a "[<<-" operator to exist. The basic raison-d'etre for the "<<-" operator is to allow one to assign objects in the global environment from within a function. But you shouldn't do it, even though it is possible!!! Modifying a component of an existing object in the global environment from within a function is even more to be avoided, it seems to me. And the designers of R seem to have drawn the line at this point. There may be conceptual difficulties with implementing a "[<<-" operator, over and above the philosophical position that using such an operator would be bad practice. I don't know. But I doubt that R Core will move to build a "[<<-" operator, even should it prove to be possible. The error message ``object "z" not found'' is certainly misleading. I don't know how hard it would be to change the code so that a more enlightening error message gets issued. Probably not worth the effort since few users would ever entertain the idea of using "[<<-". cheers, Rolf Turner ###################################################################### Attention:\ This e-mail message is privileged and confid...{{dropped:9}}
Rolf Turner <r.turner <at> auckland.ac.nz> writes:> > > On 2/07/2009, at 12:20 PM, Hsiu-Khuern Tang wrote: > > > Is this expected behavior? > > > >> z <- 1:5 > >> z[1] <<- 0 > > Error in z[1] <<- 0 : object "z" not found > > > > The documentation seems to suggest that z will be found in the global > > environment and modified accordingly. > > But I doubt that R Core will move > to build a "[<<-" operator, even should it prove to be possible.Thanks for your reply. Upon more careful reading of the manuals, I think the behavior I observed _is_ documented. The "<<-" form of assignment looks for the target variable in the enclosing environment. I had mistakenly thought that it looks for the target variable in the current or enclosing environment. This is made clear in http://cran.r-project.org/doc/manuals/R-lang.html#Subset-assignment: == snip = e<-c(a=1,b=2) i<-1 local({ e <- c(A=10,B=11) i <-2 e[i] <<- e[i]+1 }) uses the local value of i on both the LHS and RHS, and the local value of e on the RHS of the superassignment statement. It sets e in the outer environment to a b 1 12 == snip = As whether using <<- is good practice, I think there are valid and natural uses. There are some examples in the R manuals, for example, http://cran.r-project.org/doc/manuals/R-intro.html#Scope Best, Hsiu-Khuern.
On 01/07/2009 8:20 PM, Hsiu-Khuern Tang wrote:> Is this expected behavior? > >> z <- 1:5 >> z[1] <<- 0 > Error in z[1] <<- 0 : object "z" not found > > The documentation seems to suggest that z will be found in the global > environment and modified accordingly.z <<- 0 works as documented, it's the indexing that fails. (I tried other replacement functions and they also failed.) I think this case is also behaving as documented, but the docs are in the R Language Definition manual. To evaluate z[1] <<- 0 the following sequence is what is supposed to happen: - Look up z in the parent environment of the evaluation frame, and assign to a temporary variable. (This is what fails; z is in the evaluation frame, not its parent.) - Set the first element of the temporary. - Use <<- to assign the temporary to z. This might be surprising, but I think it makes sense. Using <<- when evaluating in the global environment is almost certainly an error; shouldn't R signal it as such? Duncan Murdoch
Maybe Matching Threads
- Notes on building a gcc toolchain for Rtools (but not multilib)
- Notes on building a gcc toolchain for Rtools (but not multilib)
- Notes on building a gcc toolchain for Rtools (but not multilib)
- Notes on building a gcc toolchain for Rtools (but not multilib)
- Notes on building a gcc toolchain for Rtools (but not multilib)