behavior of =

John Chambers jmc@research.bell-labs.com
Fri, 08 Nov 2002 09:15:21 -0500


It's a real confusion, but don't blame it on the use of "=" as an
assignment operator.

It's all the fault of having named arguments, which goes way back to the
dawn of time.

What you said (as opposed to what, of course, you meant) was that the
argument called "x" to "[" had the value of min(x).

The clue is that after evaluating the expression, x is unchanged
(distinctly NOT the case for the infamous C equivalent).

R> x <- runif(20)
R> y <- 1:20
R> y[x = min(x)]
numeric(0)
R> x
 [1] 0.1452749 0.4936352 0.7872399 0.4377552 0.4072236 0.4416220
0.4748017
 [8] 0.8523369 0.8870081 0.7401091 0.1480467 0.3367802 0.3825770
0.3596608
[15] 0.1040230 0.6873980 0.2974596 0.9955219 0.3217589 0.2199942

Unfortunately, the implementation of "[" doesn't check argument names
(plausibly a bug).  To see the situation more clearly, use the sort
function, whose first argument is "x".

R> sort(x=min(x))
[1] 0.1040230
which is puzzling, but:

R> sort(y=5)
Error in sort(y = 5) : unused argument(s) (y ...)

All the same, it's a useful example for a "what went wrong" FAQ.


Ben Bolker wrote:
> 
>   I probably didn't follow the discussion of allowing "=" as an assignment
> operator closely enough, but I was a little bit horrified to discover
> today (using 1.6.0; I haven't upgraded to 1.6.1 yet) that
> 
> x <- runif(20)
> y <- 1:20
> y[x=min(x)]
> 
> gives numeric(0) (because min(x) is non-integer).
> 
> x <- sample(1:20,20,TRUE)
> y[x=min(x)]
> 
> is even worse -- it gives the "wrong" answer. I know exactly what's going
> on here (the = in the subsetting statement above was a typo for ==), and I
> should have known better, but I felt like I was programming in C again!
> 
> I know that the designers tried to build in safeguards (from the man
> page):
> 
>    the `=' is only allowed at the top level (that is, in the complete
>    expression typed by the user) or as one of the subexpressions in a
>    braced list of expressions.
> 
> These safeguards don't prevent the mishap shown above.  Is there any way
> to detect this case syntactically (check for assignments inside subsetting
> operations??), or will I just have to train my students to watch out for
> this possibility?
> 
> ----
> 318 Carr Hall                                bolker@zoo.ufl.edu
> Zoology Department, University of Florida    http://www.zoo.ufl.edu/bolker
> Box 118525                                   (ph)  352-392-5697
> Gainesville, FL 32611-8525                   (fax) 352-392-3704
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
> r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
> Send "info", "help", or "[un]subscribe"
> (in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
> _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

-- 
John M. Chambers                  jmc@bell-labs.com
Bell Labs, Lucent Technologies    office: (908)582-2681
700 Mountain Avenue, Room 2C-282  fax:    (908)582-3340
Murray Hill, NJ  07974            web: http://www.cs.bell-labs.com/~jmc
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._