Pass a single argument as dots in tidyeval
I am trying to wrap dplyr::filter
within a function where when there is more than one filter
condition, then they are passed as a vector or list. See this minimal example:
filter_wrap <- function(x, filter_args) {
filter_args_enquos <- rlang::enquos(filter_args)
dplyr::filter(x, !!!filter_args_enquos)
}
When there is a single condition I can make it work:
data(iris)
message("Single condition works:")
expected <- dplyr::filter(iris, Sepal.Length > 5)
obtained <- filter_wrap(iris, filter_args = Sepal.Length > 5)
stopifnot(identical(expected, obtained))
When I try to pass more than one condition I get a problem. I was expecting that the !!!
operator in the dplyr::filter
call would splice my arguments but given the error message I guess I am understanding it wrong.
message("Multiple conditions fail:")
expected <- dplyr::filter(iris, Sepal.Length > 5, Petal.Length > 5)
obtained <- filter_wrap(iris, c(Sepal.Length > 5, Petal.Length > 5))
# Error in filter_impl(.data, quo) : Result must have length 150, not 300
# Called from: filter_impl(.data, quo)
stopifnot(identical(expected, obtained))
Using a list does change the error message:
obtained <- filter_wrap(iris, list(Sepal.Length > 5, Petal.Length > 5))
# Error in filter_impl(.data, quo) :
# Argument 2 filter condition does not evaluate to a logical vector
# Called from: filter_impl(.data, quo)
I don't want to use ...
as my function will have other arguments and I may want to use dots for something else.
How can I expand my filter_args
argument when passing it to dplyr::filter
?
r dplyr rlang
add a comment |
I am trying to wrap dplyr::filter
within a function where when there is more than one filter
condition, then they are passed as a vector or list. See this minimal example:
filter_wrap <- function(x, filter_args) {
filter_args_enquos <- rlang::enquos(filter_args)
dplyr::filter(x, !!!filter_args_enquos)
}
When there is a single condition I can make it work:
data(iris)
message("Single condition works:")
expected <- dplyr::filter(iris, Sepal.Length > 5)
obtained <- filter_wrap(iris, filter_args = Sepal.Length > 5)
stopifnot(identical(expected, obtained))
When I try to pass more than one condition I get a problem. I was expecting that the !!!
operator in the dplyr::filter
call would splice my arguments but given the error message I guess I am understanding it wrong.
message("Multiple conditions fail:")
expected <- dplyr::filter(iris, Sepal.Length > 5, Petal.Length > 5)
obtained <- filter_wrap(iris, c(Sepal.Length > 5, Petal.Length > 5))
# Error in filter_impl(.data, quo) : Result must have length 150, not 300
# Called from: filter_impl(.data, quo)
stopifnot(identical(expected, obtained))
Using a list does change the error message:
obtained <- filter_wrap(iris, list(Sepal.Length > 5, Petal.Length > 5))
# Error in filter_impl(.data, quo) :
# Argument 2 filter condition does not evaluate to a logical vector
# Called from: filter_impl(.data, quo)
I don't want to use ...
as my function will have other arguments and I may want to use dots for something else.
How can I expand my filter_args
argument when passing it to dplyr::filter
?
r dplyr rlang
add a comment |
I am trying to wrap dplyr::filter
within a function where when there is more than one filter
condition, then they are passed as a vector or list. See this minimal example:
filter_wrap <- function(x, filter_args) {
filter_args_enquos <- rlang::enquos(filter_args)
dplyr::filter(x, !!!filter_args_enquos)
}
When there is a single condition I can make it work:
data(iris)
message("Single condition works:")
expected <- dplyr::filter(iris, Sepal.Length > 5)
obtained <- filter_wrap(iris, filter_args = Sepal.Length > 5)
stopifnot(identical(expected, obtained))
When I try to pass more than one condition I get a problem. I was expecting that the !!!
operator in the dplyr::filter
call would splice my arguments but given the error message I guess I am understanding it wrong.
message("Multiple conditions fail:")
expected <- dplyr::filter(iris, Sepal.Length > 5, Petal.Length > 5)
obtained <- filter_wrap(iris, c(Sepal.Length > 5, Petal.Length > 5))
# Error in filter_impl(.data, quo) : Result must have length 150, not 300
# Called from: filter_impl(.data, quo)
stopifnot(identical(expected, obtained))
Using a list does change the error message:
obtained <- filter_wrap(iris, list(Sepal.Length > 5, Petal.Length > 5))
# Error in filter_impl(.data, quo) :
# Argument 2 filter condition does not evaluate to a logical vector
# Called from: filter_impl(.data, quo)
I don't want to use ...
as my function will have other arguments and I may want to use dots for something else.
How can I expand my filter_args
argument when passing it to dplyr::filter
?
r dplyr rlang
I am trying to wrap dplyr::filter
within a function where when there is more than one filter
condition, then they are passed as a vector or list. See this minimal example:
filter_wrap <- function(x, filter_args) {
filter_args_enquos <- rlang::enquos(filter_args)
dplyr::filter(x, !!!filter_args_enquos)
}
When there is a single condition I can make it work:
data(iris)
message("Single condition works:")
expected <- dplyr::filter(iris, Sepal.Length > 5)
obtained <- filter_wrap(iris, filter_args = Sepal.Length > 5)
stopifnot(identical(expected, obtained))
When I try to pass more than one condition I get a problem. I was expecting that the !!!
operator in the dplyr::filter
call would splice my arguments but given the error message I guess I am understanding it wrong.
message("Multiple conditions fail:")
expected <- dplyr::filter(iris, Sepal.Length > 5, Petal.Length > 5)
obtained <- filter_wrap(iris, c(Sepal.Length > 5, Petal.Length > 5))
# Error in filter_impl(.data, quo) : Result must have length 150, not 300
# Called from: filter_impl(.data, quo)
stopifnot(identical(expected, obtained))
Using a list does change the error message:
obtained <- filter_wrap(iris, list(Sepal.Length > 5, Petal.Length > 5))
# Error in filter_impl(.data, quo) :
# Argument 2 filter condition does not evaluate to a logical vector
# Called from: filter_impl(.data, quo)
I don't want to use ...
as my function will have other arguments and I may want to use dots for something else.
How can I expand my filter_args
argument when passing it to dplyr::filter
?
r dplyr rlang
r dplyr rlang
asked Nov 13 '18 at 12:16
zeehiozeehio
1,93712028
1,93712028
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
Basically your problem is that when you call enquos()
on the single parameter, you are also quoting the list()
call (which is a single call). So basically you are creating
filter_args_enquos <- quo(list(Sepal.Length > 5, Petal.Length > 5))
and when you call
dplyr::filter(iris, !!!filter_args_enquos)
that's the same as
dplyr::filter(iris, list(Sepal.Length > 5, Petal.Length > 5))
which isn't valid dplyr syntax. The !!!
needs to work on a proper list-like object, not an un-evaluated call to a list, note that this would work
filter_args_enquos <- list(quo(Sepal.Length > 5), quo(Petal.Length > 5))
dplyr::filter(iris, !!!filter_args_enquos)
because here we are actually evaluating the list, and only quoting the things inside the list. This is basically the type of object created by enquos when using ...
filter_wrap <- function(x, ...) {
filter_args_enquos <- rlang::enquos(...)
dplyr::filter(x, !!!filter_args_enquos)
}
filter_wrap(iris, Sepal.Length > 5, Petal.Length > 5)
The enquos()
function expects multiple parameters, not just a single list. That's why it's meant to be used with ...
because that will expand to multiple parameters. If you want to possibly pass in a list, you can write a helper function that can look for this special case and expand the quosure properly. For example
expand_list_quos <- function(x) {
expr <- rlang::quo_get_expr(x)
if (expr[[1]]==as.name("list")) {
expr[[1]] <- as.name("quos")
return(rlang::eval_tidy(expr, env = rlang::quo_get_env(x)))
} else {
return(x)
}
}
Then you can use it with
filter_wrap <- function(x, filter_args) {
filter_args <- expand_list_quos(rlang::enquo(filter_args))
dplyr::filter(x, !!!filter_args)
}
and both of these will work
filter_wrap(iris, Petal.Length > 5)
filter_wrap(iris, list(Sepal.Length > 5, Petal.Length > 5))
but this is not really the way this enquo
stuff is "meant" to be used. The ...
method is much more idiomatic. Or calling quos()
explicitly if you need more control
filter_wrap <- function(x, filter_args) {
dplyr::filter(x, !!!filter_args)
}
filter_wrap(iris, quo(Petal.Length > 5))
filter_wrap(iris, quos(Sepal.Length > 5, Petal.Length > 5))
Thanks! I get it now! I will consider your suggestion about not being really the wayenquo
is meant to be used and usequos
instead... In any case, can it be that therlang::eval_tidy(expr)
call should actually berlang::eval_tidy(expr, env = rlang::quo_get_env(x))
so it is evaluated in the environment fromx
?
– zeehio
Nov 13 '18 at 16:55
Sure. If your actual use case was using variables from places other than the columns of the data.frame, you would want to capture the right environment.
– MrFlick
Nov 13 '18 at 18:50
add a comment |
I hope I understood it right, here is a quick'n'dirty solution:
The problem is / was that by combining your logic queries combined by c which results in a vector as long as x * n of comparisons.
filter_wrap <- function(x, filter_args) {
filter_args_enquos <- rlang::enquos(filter_args)
LogVec <- rowwise(x) %>% mutate(LogVec = all(!!!filter_args_enquos)) %>%
pull(LogVec)
dplyr::filter(x, LogVec)
}
expected <- dplyr::filter(iris, Sepal.Length > 5, Petal.Length > 5)
obtained <- filter_wrap(iris, c(Sepal.Length > 5, Petal.Length > 5))
stopifnot(identical(expected, obtained))
Ideally I would like to understand how to make it work with rlang, but your quick'n'dirty solution solves my problem :-)
– zeehio
Nov 13 '18 at 15:34
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53280843%2fpass-a-single-argument-as-dots-in-tidyeval%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Basically your problem is that when you call enquos()
on the single parameter, you are also quoting the list()
call (which is a single call). So basically you are creating
filter_args_enquos <- quo(list(Sepal.Length > 5, Petal.Length > 5))
and when you call
dplyr::filter(iris, !!!filter_args_enquos)
that's the same as
dplyr::filter(iris, list(Sepal.Length > 5, Petal.Length > 5))
which isn't valid dplyr syntax. The !!!
needs to work on a proper list-like object, not an un-evaluated call to a list, note that this would work
filter_args_enquos <- list(quo(Sepal.Length > 5), quo(Petal.Length > 5))
dplyr::filter(iris, !!!filter_args_enquos)
because here we are actually evaluating the list, and only quoting the things inside the list. This is basically the type of object created by enquos when using ...
filter_wrap <- function(x, ...) {
filter_args_enquos <- rlang::enquos(...)
dplyr::filter(x, !!!filter_args_enquos)
}
filter_wrap(iris, Sepal.Length > 5, Petal.Length > 5)
The enquos()
function expects multiple parameters, not just a single list. That's why it's meant to be used with ...
because that will expand to multiple parameters. If you want to possibly pass in a list, you can write a helper function that can look for this special case and expand the quosure properly. For example
expand_list_quos <- function(x) {
expr <- rlang::quo_get_expr(x)
if (expr[[1]]==as.name("list")) {
expr[[1]] <- as.name("quos")
return(rlang::eval_tidy(expr, env = rlang::quo_get_env(x)))
} else {
return(x)
}
}
Then you can use it with
filter_wrap <- function(x, filter_args) {
filter_args <- expand_list_quos(rlang::enquo(filter_args))
dplyr::filter(x, !!!filter_args)
}
and both of these will work
filter_wrap(iris, Petal.Length > 5)
filter_wrap(iris, list(Sepal.Length > 5, Petal.Length > 5))
but this is not really the way this enquo
stuff is "meant" to be used. The ...
method is much more idiomatic. Or calling quos()
explicitly if you need more control
filter_wrap <- function(x, filter_args) {
dplyr::filter(x, !!!filter_args)
}
filter_wrap(iris, quo(Petal.Length > 5))
filter_wrap(iris, quos(Sepal.Length > 5, Petal.Length > 5))
Thanks! I get it now! I will consider your suggestion about not being really the wayenquo
is meant to be used and usequos
instead... In any case, can it be that therlang::eval_tidy(expr)
call should actually berlang::eval_tidy(expr, env = rlang::quo_get_env(x))
so it is evaluated in the environment fromx
?
– zeehio
Nov 13 '18 at 16:55
Sure. If your actual use case was using variables from places other than the columns of the data.frame, you would want to capture the right environment.
– MrFlick
Nov 13 '18 at 18:50
add a comment |
Basically your problem is that when you call enquos()
on the single parameter, you are also quoting the list()
call (which is a single call). So basically you are creating
filter_args_enquos <- quo(list(Sepal.Length > 5, Petal.Length > 5))
and when you call
dplyr::filter(iris, !!!filter_args_enquos)
that's the same as
dplyr::filter(iris, list(Sepal.Length > 5, Petal.Length > 5))
which isn't valid dplyr syntax. The !!!
needs to work on a proper list-like object, not an un-evaluated call to a list, note that this would work
filter_args_enquos <- list(quo(Sepal.Length > 5), quo(Petal.Length > 5))
dplyr::filter(iris, !!!filter_args_enquos)
because here we are actually evaluating the list, and only quoting the things inside the list. This is basically the type of object created by enquos when using ...
filter_wrap <- function(x, ...) {
filter_args_enquos <- rlang::enquos(...)
dplyr::filter(x, !!!filter_args_enquos)
}
filter_wrap(iris, Sepal.Length > 5, Petal.Length > 5)
The enquos()
function expects multiple parameters, not just a single list. That's why it's meant to be used with ...
because that will expand to multiple parameters. If you want to possibly pass in a list, you can write a helper function that can look for this special case and expand the quosure properly. For example
expand_list_quos <- function(x) {
expr <- rlang::quo_get_expr(x)
if (expr[[1]]==as.name("list")) {
expr[[1]] <- as.name("quos")
return(rlang::eval_tidy(expr, env = rlang::quo_get_env(x)))
} else {
return(x)
}
}
Then you can use it with
filter_wrap <- function(x, filter_args) {
filter_args <- expand_list_quos(rlang::enquo(filter_args))
dplyr::filter(x, !!!filter_args)
}
and both of these will work
filter_wrap(iris, Petal.Length > 5)
filter_wrap(iris, list(Sepal.Length > 5, Petal.Length > 5))
but this is not really the way this enquo
stuff is "meant" to be used. The ...
method is much more idiomatic. Or calling quos()
explicitly if you need more control
filter_wrap <- function(x, filter_args) {
dplyr::filter(x, !!!filter_args)
}
filter_wrap(iris, quo(Petal.Length > 5))
filter_wrap(iris, quos(Sepal.Length > 5, Petal.Length > 5))
Thanks! I get it now! I will consider your suggestion about not being really the wayenquo
is meant to be used and usequos
instead... In any case, can it be that therlang::eval_tidy(expr)
call should actually berlang::eval_tidy(expr, env = rlang::quo_get_env(x))
so it is evaluated in the environment fromx
?
– zeehio
Nov 13 '18 at 16:55
Sure. If your actual use case was using variables from places other than the columns of the data.frame, you would want to capture the right environment.
– MrFlick
Nov 13 '18 at 18:50
add a comment |
Basically your problem is that when you call enquos()
on the single parameter, you are also quoting the list()
call (which is a single call). So basically you are creating
filter_args_enquos <- quo(list(Sepal.Length > 5, Petal.Length > 5))
and when you call
dplyr::filter(iris, !!!filter_args_enquos)
that's the same as
dplyr::filter(iris, list(Sepal.Length > 5, Petal.Length > 5))
which isn't valid dplyr syntax. The !!!
needs to work on a proper list-like object, not an un-evaluated call to a list, note that this would work
filter_args_enquos <- list(quo(Sepal.Length > 5), quo(Petal.Length > 5))
dplyr::filter(iris, !!!filter_args_enquos)
because here we are actually evaluating the list, and only quoting the things inside the list. This is basically the type of object created by enquos when using ...
filter_wrap <- function(x, ...) {
filter_args_enquos <- rlang::enquos(...)
dplyr::filter(x, !!!filter_args_enquos)
}
filter_wrap(iris, Sepal.Length > 5, Petal.Length > 5)
The enquos()
function expects multiple parameters, not just a single list. That's why it's meant to be used with ...
because that will expand to multiple parameters. If you want to possibly pass in a list, you can write a helper function that can look for this special case and expand the quosure properly. For example
expand_list_quos <- function(x) {
expr <- rlang::quo_get_expr(x)
if (expr[[1]]==as.name("list")) {
expr[[1]] <- as.name("quos")
return(rlang::eval_tidy(expr, env = rlang::quo_get_env(x)))
} else {
return(x)
}
}
Then you can use it with
filter_wrap <- function(x, filter_args) {
filter_args <- expand_list_quos(rlang::enquo(filter_args))
dplyr::filter(x, !!!filter_args)
}
and both of these will work
filter_wrap(iris, Petal.Length > 5)
filter_wrap(iris, list(Sepal.Length > 5, Petal.Length > 5))
but this is not really the way this enquo
stuff is "meant" to be used. The ...
method is much more idiomatic. Or calling quos()
explicitly if you need more control
filter_wrap <- function(x, filter_args) {
dplyr::filter(x, !!!filter_args)
}
filter_wrap(iris, quo(Petal.Length > 5))
filter_wrap(iris, quos(Sepal.Length > 5, Petal.Length > 5))
Basically your problem is that when you call enquos()
on the single parameter, you are also quoting the list()
call (which is a single call). So basically you are creating
filter_args_enquos <- quo(list(Sepal.Length > 5, Petal.Length > 5))
and when you call
dplyr::filter(iris, !!!filter_args_enquos)
that's the same as
dplyr::filter(iris, list(Sepal.Length > 5, Petal.Length > 5))
which isn't valid dplyr syntax. The !!!
needs to work on a proper list-like object, not an un-evaluated call to a list, note that this would work
filter_args_enquos <- list(quo(Sepal.Length > 5), quo(Petal.Length > 5))
dplyr::filter(iris, !!!filter_args_enquos)
because here we are actually evaluating the list, and only quoting the things inside the list. This is basically the type of object created by enquos when using ...
filter_wrap <- function(x, ...) {
filter_args_enquos <- rlang::enquos(...)
dplyr::filter(x, !!!filter_args_enquos)
}
filter_wrap(iris, Sepal.Length > 5, Petal.Length > 5)
The enquos()
function expects multiple parameters, not just a single list. That's why it's meant to be used with ...
because that will expand to multiple parameters. If you want to possibly pass in a list, you can write a helper function that can look for this special case and expand the quosure properly. For example
expand_list_quos <- function(x) {
expr <- rlang::quo_get_expr(x)
if (expr[[1]]==as.name("list")) {
expr[[1]] <- as.name("quos")
return(rlang::eval_tidy(expr, env = rlang::quo_get_env(x)))
} else {
return(x)
}
}
Then you can use it with
filter_wrap <- function(x, filter_args) {
filter_args <- expand_list_quos(rlang::enquo(filter_args))
dplyr::filter(x, !!!filter_args)
}
and both of these will work
filter_wrap(iris, Petal.Length > 5)
filter_wrap(iris, list(Sepal.Length > 5, Petal.Length > 5))
but this is not really the way this enquo
stuff is "meant" to be used. The ...
method is much more idiomatic. Or calling quos()
explicitly if you need more control
filter_wrap <- function(x, filter_args) {
dplyr::filter(x, !!!filter_args)
}
filter_wrap(iris, quo(Petal.Length > 5))
filter_wrap(iris, quos(Sepal.Length > 5, Petal.Length > 5))
edited Nov 14 '18 at 17:16
answered Nov 13 '18 at 15:43
MrFlickMrFlick
120k11134162
120k11134162
Thanks! I get it now! I will consider your suggestion about not being really the wayenquo
is meant to be used and usequos
instead... In any case, can it be that therlang::eval_tidy(expr)
call should actually berlang::eval_tidy(expr, env = rlang::quo_get_env(x))
so it is evaluated in the environment fromx
?
– zeehio
Nov 13 '18 at 16:55
Sure. If your actual use case was using variables from places other than the columns of the data.frame, you would want to capture the right environment.
– MrFlick
Nov 13 '18 at 18:50
add a comment |
Thanks! I get it now! I will consider your suggestion about not being really the wayenquo
is meant to be used and usequos
instead... In any case, can it be that therlang::eval_tidy(expr)
call should actually berlang::eval_tidy(expr, env = rlang::quo_get_env(x))
so it is evaluated in the environment fromx
?
– zeehio
Nov 13 '18 at 16:55
Sure. If your actual use case was using variables from places other than the columns of the data.frame, you would want to capture the right environment.
– MrFlick
Nov 13 '18 at 18:50
Thanks! I get it now! I will consider your suggestion about not being really the way
enquo
is meant to be used and use quos
instead... In any case, can it be that the rlang::eval_tidy(expr)
call should actually be rlang::eval_tidy(expr, env = rlang::quo_get_env(x))
so it is evaluated in the environment from x
?– zeehio
Nov 13 '18 at 16:55
Thanks! I get it now! I will consider your suggestion about not being really the way
enquo
is meant to be used and use quos
instead... In any case, can it be that the rlang::eval_tidy(expr)
call should actually be rlang::eval_tidy(expr, env = rlang::quo_get_env(x))
so it is evaluated in the environment from x
?– zeehio
Nov 13 '18 at 16:55
Sure. If your actual use case was using variables from places other than the columns of the data.frame, you would want to capture the right environment.
– MrFlick
Nov 13 '18 at 18:50
Sure. If your actual use case was using variables from places other than the columns of the data.frame, you would want to capture the right environment.
– MrFlick
Nov 13 '18 at 18:50
add a comment |
I hope I understood it right, here is a quick'n'dirty solution:
The problem is / was that by combining your logic queries combined by c which results in a vector as long as x * n of comparisons.
filter_wrap <- function(x, filter_args) {
filter_args_enquos <- rlang::enquos(filter_args)
LogVec <- rowwise(x) %>% mutate(LogVec = all(!!!filter_args_enquos)) %>%
pull(LogVec)
dplyr::filter(x, LogVec)
}
expected <- dplyr::filter(iris, Sepal.Length > 5, Petal.Length > 5)
obtained <- filter_wrap(iris, c(Sepal.Length > 5, Petal.Length > 5))
stopifnot(identical(expected, obtained))
Ideally I would like to understand how to make it work with rlang, but your quick'n'dirty solution solves my problem :-)
– zeehio
Nov 13 '18 at 15:34
add a comment |
I hope I understood it right, here is a quick'n'dirty solution:
The problem is / was that by combining your logic queries combined by c which results in a vector as long as x * n of comparisons.
filter_wrap <- function(x, filter_args) {
filter_args_enquos <- rlang::enquos(filter_args)
LogVec <- rowwise(x) %>% mutate(LogVec = all(!!!filter_args_enquos)) %>%
pull(LogVec)
dplyr::filter(x, LogVec)
}
expected <- dplyr::filter(iris, Sepal.Length > 5, Petal.Length > 5)
obtained <- filter_wrap(iris, c(Sepal.Length > 5, Petal.Length > 5))
stopifnot(identical(expected, obtained))
Ideally I would like to understand how to make it work with rlang, but your quick'n'dirty solution solves my problem :-)
– zeehio
Nov 13 '18 at 15:34
add a comment |
I hope I understood it right, here is a quick'n'dirty solution:
The problem is / was that by combining your logic queries combined by c which results in a vector as long as x * n of comparisons.
filter_wrap <- function(x, filter_args) {
filter_args_enquos <- rlang::enquos(filter_args)
LogVec <- rowwise(x) %>% mutate(LogVec = all(!!!filter_args_enquos)) %>%
pull(LogVec)
dplyr::filter(x, LogVec)
}
expected <- dplyr::filter(iris, Sepal.Length > 5, Petal.Length > 5)
obtained <- filter_wrap(iris, c(Sepal.Length > 5, Petal.Length > 5))
stopifnot(identical(expected, obtained))
I hope I understood it right, here is a quick'n'dirty solution:
The problem is / was that by combining your logic queries combined by c which results in a vector as long as x * n of comparisons.
filter_wrap <- function(x, filter_args) {
filter_args_enquos <- rlang::enquos(filter_args)
LogVec <- rowwise(x) %>% mutate(LogVec = all(!!!filter_args_enquos)) %>%
pull(LogVec)
dplyr::filter(x, LogVec)
}
expected <- dplyr::filter(iris, Sepal.Length > 5, Petal.Length > 5)
obtained <- filter_wrap(iris, c(Sepal.Length > 5, Petal.Length > 5))
stopifnot(identical(expected, obtained))
answered Nov 13 '18 at 14:49
floefloe
268210
268210
Ideally I would like to understand how to make it work with rlang, but your quick'n'dirty solution solves my problem :-)
– zeehio
Nov 13 '18 at 15:34
add a comment |
Ideally I would like to understand how to make it work with rlang, but your quick'n'dirty solution solves my problem :-)
– zeehio
Nov 13 '18 at 15:34
Ideally I would like to understand how to make it work with rlang, but your quick'n'dirty solution solves my problem :-)
– zeehio
Nov 13 '18 at 15:34
Ideally I would like to understand how to make it work with rlang, but your quick'n'dirty solution solves my problem :-)
– zeehio
Nov 13 '18 at 15:34
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53280843%2fpass-a-single-argument-as-dots-in-tidyeval%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown