dplyr redefining summarise changes behavior of plyr

[deaneckles]

Reference to just-created variables in summarise no longer work in some cases because (I'd guess) of non-standard evaluation stuff.

In particular, run the following code either with just library(plyr) or with library(plyr); library(dplyr).
The former works fine. the latter fails with "Error: object 'r' not found"

tmp <- expand.grid(a = 1:3, b = 0:1, i = 1:10)
ddply(
  tmp, .(a), summarise, 
  r = sum(b),
  n = length(b),
  p = prop.test(r, n, p = 0.05)$conf.int[1]
  )

This seems to be caused by the index [1]. Without this (and replacing $conf.int with $p.value, so that there is only one value), this works fine with both sets of libraries.

[hadley]

Do you have both plyr and dplyr loaded? Attempting to use them in this way is likely to lead to problems.

[deaneckles]

Yes, this is caused when having loaded both (but in the suggested order). I figured because of #29 that making them compatible is a goal.

I guess the best solution to this problem is to use plyr::summarise explicitly.

[hadley]

Ah, got it - I'll take a look.

[hadley]

Ok, a slightly improved reproducible example:

tmp <- expand.grid(a = 1:3, b = 0:1, i = 1:10)

# FAILS
plyr::ddply(tmp, "a", dplyr::summarise, 
  r = sum(b),
  n = length(b),
  p = prop.test(r, n, p = 0.05)$conf.int[1]
)

# WORKS
plyr::ddply(tmp, "a", dplyr::summarise, 
  r = sum(b),
  n = length(b),
  p = prop.test(r, n, p = 0.05)$p.value
)

[hadley]

Ok, turns out this is unrelated to plyr:

library(dplyr)

# FAILS
tmp %>% group_by(a) %>%
  summarise(
    r = sum(b),
    n = length(b),
    p = prop.test(r, n, p = 0.05)$conf.int[1]
  )

# WORKS
tmp %>% group_by(a) %>%
  summarise(
    r = sum(b),
    n = length(b),
    p = prop.test(r, n, p = 0.05)$p.value
  )

[hadley]

@deaneckles did this work in dplyr 0.2?

[hadley]

@romainfrancois can you please take a look? Looks like a hybrid eval problem.

[romainfrancois]

Sure. I think it is more or less the same problem as in #421

[romainfrancois]

I think I fixed that class of problems, i.e. expressions of the general form foo( bar = yada)$bah( bling = 2) i.e. calls appearing either on the left or right of $.

The previous implementation was trying to do too much too early.