Why is `[` better than `subset`?

r filter subset r-faq

When I need to filter a data.frame, i.e., extract rows that meet certain conditions, I prefer to use the subset function:

subset(airquality, Month == 8 & Temp > 90)

Rather than the [ function:

airquality[airquality$Month == 8 & airquality$Temp > 90, ]

There are two main reasons for my preference:

I find the code reads better, from left to right. Even people who know nothing about R could tell what the subset statement above is doing. Because columns can be referred to as variables in the select expression, I can save a few keystrokes. In my example above, I only had to type airquality once with subset, but three times with [.

So I was living happy, using subset everywhere because it is shorter and reads better, even advocating its beauty to my fellow R coders. But yesterday my world broke apart. While reading the subset documentation, I notice this section:

Warning This is a convenience function intended for use interactively. For programming it is better to use the standard subsetting functions like [, and in particular the non-standard evaluation of argument subset can have unanticipated consequences.

Could someone help clarify what the authors mean?

First, what do they mean by "for use interactively"? I know what an interactive session is, as opposed to a script run in BATCH mode but I don't see what difference it should make.

Then, could you please explain "the non-standard evaluation of argument subset" and why it is dangerous, maybe provide an example?

It is slightly less (but nut less than subset) to use with, with(airquality, airquality[Month == 8 & Temp > 90, ])

You might also have a look at Cirlces 8.2.31 and 8.2.32 of 'The R Inferno' burns-stat.com/pages/Tutor/R_inferno.pdf

Try data.table instead, the default syntax is like airquality[Month == 8 & Temp > 90,] - very readable, and much faster.

OK. so if subset is bad to use - what about [ vs. dplyr::filter() ?

For those wondering, dplyr::filter has the same problem. I.e. if the environment happens to have a variable with that name, it will use it instead of the variable in the data frame. Makes for confusing debugging!

4 revs, 3 users 91%

This question was answered in well in the comments by @James, pointing to an excellent explanation by Hadley Wickham of the dangers of subset (and functions like it) [here]. Go read it!

It's a somewhat long read, so it may be helpful to record here the example that Hadley uses that most directly addresses the question of "what can go wrong?":

Hadley suggests the following example: suppose we want to subset and then reorder a data frame using the following functions:

scramble <- function(x) x[sample(nrow(x)), ]

subscramble <- function(x, condition) {
  scramble(subset(x, condition))
}

subscramble(mtcars, cyl == 4)

This returns the error:

Error in eval(expr, envir, enclos) : object 'cyl' not found

because R no longer "knows" where to find the object called 'cyl'. He also points out the truly bizarre stuff that can happen if by chance there is an object called 'cyl' in the global environment:

cyl <- 4
subscramble(mtcars, cyl == 4)

cyl <- sample(10, 100, rep = T)
subscramble(mtcars, cyl == 4)

(Run them and see for yourself, it's pretty crazy.)

May I have some newbie questions for clarification? When we write subset(mtcars, cyl == 4) (at top level), where does R look for cyl? If it looks into the mtcars object that is passed to subset(), then shouldn't it be able to find cyl even if scramble is within another function, since mtcars is still being passed to it? If my question doesn't make sense, you could just elaborate more on why R can no longer find cyl. Thanks!

@Anh Inside subset.data.frame, the thing we're trying to evaluate at that point is just condition. That doesn't exist in mtcars. So subset.data.frame uses enclos = parent.frame() to ensure that condition is correctly evaluated as cyl == 4. But then we've popped back up to the enclosing frame, and now when R looks for cyl it is no longer looking inside of mtcars. If we didn't use enclos, something like subset(mtcars,cyl == a) wouldn't work at all.

@MikePalmice It does. The last line of subset.data.frame is x[r, vars, drop = drop]. The problem is how to get from the unquoted subset and select arguments to something that you can validly pass to [.data.frame.

This is such an old question/answer with so many upvotes - so clearly I am overlooking something?? For me, your example code doesn't work on it's own. Hadley's example contains the pre-creation of another function called 'subset2'... The important difference between [ and subset() lies then within this function...

Thanks for checking. I might have misunderstood the intention of your code. But replacing it with subset using [, this results in the same 'weird' result as your code using subset - at least here :/ Also clean R 3.4.3

bartektartanus

Also [ is faster:

require(microbenchmark)        
microbenchmark(subset(airquality, Month == 8 & Temp > 90),airquality[airquality$Month == 8 & airquality$Temp > 90,])
    Unit: microseconds
                                                           expr     min       lq   median       uq     max neval
                     subset(airquality, Month == 8 & Temp > 90) 301.994 312.1565 317.3600 349.4170 500.903   100
     airquality[airquality$Month == 8 & airquality$Temp > 90, ] 234.807 239.3125 244.2715 271.7885 340.058   100

Yes and no. I think the time difference you are seeing is due to two things. 1) a small (< 100 microseconds) overhead and 2) subset unlike [ removes rows where the filter evaluates to NA. Do this and you'll see that they are both as fast when compared "fairly":

x <- do.call(rbind, rep(list(airquality), 100)); microbenchmark(subset(x, Month == 8 & Temp > 90),{ i <- x$Month == 8 & x$Temp > 90; x[!is.na(i) & i ,] })

Why is `[` better than `subset`?

Follow WeChat

Want to stay one step ahead of the latest teleworks?

相似问题

Platform

Support

Contact US