Closed multimeric closed 1 year ago
This isn't a bug, it is just an unfortunate side effect that can occur when nesting mutate()
or summarise()
calls. Luckily that isn't really all that common.
When you do
per_group = function(i, grp){
dplyr::mutate(grp, name=paste0(Species, i))
}
data %>%
dplyr::summarise(per_group(dplyr::cur_group_id(), dplyr::cur_data_all()))
i
is bound to dplyr::cur_group_id()
but the value of i
isn't actually finalized until it is utilized in
dplyr::mutate(grp, name=paste0(Species, i))
At that point, i
resolves to dplyr::cur_group_id()
and that tries to evaluate, but at that point you are inside mutate()
, so it uses the cur_group_id()
related to grp
, not the original data
.
When you force it early with
per_group = function(i, grp){
force(i)
dplyr::mutate(grp, name=paste0(Species, i))
}
then the evaluation of cur_group_id()
happens within the summarise()
call instead, so it is tied to data
as you expected.
This is just part of how R works, so I think it is out of scope to try and work around this here
Here's a very weird bug I just encountered. The idea is that we want to run a function per group, which mutates that group to add a new column involving
i
, the current group ID. What should happen is that we get"setosa1" "versicolor2" "virginica3"
as the ID is incremented per group, but in reality they are all fixed at 1.It's a very contrived example but it's the simplest way I've found to reproduce this bug.
dplyr::group_map
is probably a more elegant way to solve this but I dare not use experimental functions.Created on 2023-02-20 with reprex v2.0.2
What is super interesting to me is that if we
force
the promisei
to evaluate, it works correctly, which to me implies that the fault lies in handling promises:Created on 2023-02-20 with reprex v2.0.2
Versions: