seplyr is an R package that makes it easy to program over dplyr 0.7.*.
To illustrate this we will work an example.
Continue reading Tutorial: Using seplyr to Program Over dplyr
Category: Coding
wrapr Implementation Update
Introduction
The development version CRAN version of our R helper function wrapr::let() has switched from string-based substitution to abstract syntax tree based substitution (AST based substitution, or language based substitution).
I am looking for some feedback from wrapr::let() users already doing substantial work with wrapr::let(). If you are already using wrapr::let() please test if the current development version of wrapr works with your code. If you run into problems: I apologize, and please file a GitHub issue.
Non-Standard Evaluation and Function Composition in R
In this article we will discuss composing standard-evaluation interfaces (SE: parametric, referentially transparent, or “looks only at values”) and composing non-standard-evaluation interfaces (NSE) in R.
In R the package tidyeval/rlang is a tool for building domain specific languages intended to allow easier composition of NSE interfaces.
To use it you must know some of its structure and notation. Here are some details paraphrased from the major tidyeval/rlang client, the package dplyr: vignette('programming', package = 'dplyr')).
- "
:=" is needed to make left-hand-side re-mapping possible (adding yet another "more than one assignment type operator running around" notation issue). - "
!!" substitution requires parenthesis to safely bind (so the notation is actually "(!! )", not "!!"). - Left-hand-sides of expressions are names or strings, while right-hand-sides are
quosures/expressions.
Continue reading Non-Standard Evaluation and Function Composition in R
More on safe substitution in R
Let’s worry a bit about substitution in R. Substitution is very powerful, which means it can be both used and mis-used. However, that does not mean every use is unsafe or a mistake.
In defense of wrapr::let()
Saw this the other day:
In defense of wrapr::let() (originally part of replyr, and still re-exported by that package) I would say:
let()was deliberately designed for a single real-world use case: working with data when you don’t know the column names when you are writing the code (i.e., the column names will come later in a variable). We can re-phrase that as: there is deliberately less to learn aslet()is adapted to a need (instead of one having to adapt tolet()).- The
Rcommunity already has months of experience confirminglet()working reliably in production while interacting with a number of different packages. let()will continue to be a very specific, consistent, reliable, and relevant tool even afterdpyr 0.6.*is released, and the community gains experience withrlang/tidyevalin production.
If rlang/tidyeval is your thing, by all means please use and teach it. But please continue to consider also using wrapr::let(). If you are trying to get something done quickly, or trying to share work with others: a “deeper theory” may not be the best choice.
An example follows. Continue reading In defense of wrapr::let()
Why to use wrapr::let()
I have written about referential transparency before. In this article I would like to discuss “leaky abstractions” and why wrapr::let() supplies a useful (but leaky) abstraction for R programmers.
Another R [Non-]Standard Evaluation Idea
Jonathan Carroll had a an interesting R language idea: to use @-notation to request value substitution in a non-standard evaluation environment (inspired by msyql User-Defined Variables).
He even picked the right image:
wrapr: for sweet R code
This article is on writing sweet R code using the wrapr package.
Comparative examples using replyr::let
Consider the problem of “parametric programming” in R. That is: simply writing correct code before knowing some details, such as the names of the columns your procedure will have to be applied to in the future. Our latest version of replyr::let makes such programming easier.
Archie’s Mechanics #2 (1954) copyright Archie Publications
(edit: great news! CRAN just accepted our replyr 0.2.0 fix release!)
Please read on for examples comparing standard notations and replyr::let. Continue reading Comparative examples using replyr::let
A Simple Example of Using replyr::gapply
It’s a common situation to have data from multiple processes in a “long” data format, for example a table with columns measurement and process_that_produced_measurement. It’s also natural to split that data apart to analyze or transform it, per-process — and then to bring the results of that data processing together, for comparison. Such a work pattern is called “Split-Apply-Combine,” and we discuss several R implementations of this pattern here. In this article we show a simple example of one such implementation, replyr::gapply, from our latest package, replyr.
Illustration by Boris Artzybasheff. Image: James Vaughn, some rights reserved.
The example task is to evaluate how several different models perform on the same classification problem, in terms of deviance, accuracy, precision and recall. We will use the “default of credit card clients” data set from the UCI Machine Learning Repository.