Pass a single argument as dots in tidyeval












6















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?










share|improve this question



























    6















    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?










    share|improve this question

























      6












      6








      6


      2






      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?










      share|improve this question














      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






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Nov 13 '18 at 12:16









      zeehiozeehio

      1,93712028




      1,93712028
























          2 Answers
          2






          active

          oldest

          votes


















          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))





          share|improve this answer


























          • 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



















          1














          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))





          share|improve this answer
























          • 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











          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
          });


          }
          });














          draft saved

          draft discarded


















          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









          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))





          share|improve this answer


























          • 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
















          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))





          share|improve this answer


























          • 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














          5












          5








          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))





          share|improve this answer















          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))






          share|improve this answer














          share|improve this answer



          share|improve this answer








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



















          • 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

















          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













          1














          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))





          share|improve this answer
























          • 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
















          1














          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))





          share|improve this answer
























          • 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














          1












          1








          1







          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))





          share|improve this answer













          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))






          share|improve this answer












          share|improve this answer



          share|improve this answer










          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



















          • 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


















          draft saved

          draft discarded




















































          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.




          draft saved


          draft discarded














          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





















































          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







          Popular posts from this blog

          Bressuire

          Vorschmack

          Quarantine