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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._