Our group has done a lot of work with non-standard calling conventions in R.
Our tools work hard to eliminate non-standard calling (as is the purpose of wrapr::let()), or at least make it cleaner and more controllable (as is done in the wrapr dot pipe). And even so, we still get surprised by some of the side-effects and mal-consequences of the over-use of non-standard calling conventions in R.
Please read on for a recent example.
R Tip: be wary of “...“.
The following code example contains an easy error in using the R function unique().
vec1 <- c("a", "b", "c")
vec2 <- c("c", "d")
unique(vec1, vec2)
# [1] "a" "b" "c"
Notice none of the novel values from vec2 are present in the result. Our mistake was: we (improperly) tried to use unique() with multiple value arguments, as one would use union(). Also notice no error or warning was signaled. We used unique() incorrectly and nothing pointed this out to us. What compounded our error was R‘s “...” function signature feature.
In this note I will talk a bit about how to defend against this kind of mistake. I am going to apply the principle that a design that makes committing mistakes more difficult (or even impossible) is a good thing, and not a sign of carelessness, laziness, or weakness. I am well aware that every time I admit to making a mistake (I have indeed made the above mistake) those who claim to never make mistakes have a laugh at my expense. Honestly I feel the reason I see more mistakes is I check a lot more.
R has a lot of under-appreciated super powerful functions. I list a few of our favorites below.
Atlas, carrying the sky. Royal Palace (Paleis op de Dam), Amsterdam.
Photo: Dominik Bartsch, CC some rights reserved.
stringsAsFactors = FALSEstringsAsFactors = FALSETake care if trying the new RPostgres database connection package. By default it returns some non-standard types that code developed against other database drivers may not expect, and may not be ready to defend against.
Danger, Will Robinson!
Some days I see R as an eclectic programming language preferred by scientists.
“Programming languages as people.”
Other days I see it more like the following.
for() Class Loss Issuesfor() Class Loss IssuesHere is an R tip. Use loop indices to avoid for()-loops damaging classes.
Below is an R annoyance that occurs again and again: vectors lose class attributes when you iterate over them in a for()-loop.
d <- c(Sys.time(), Sys.time())
print(d)
#> [1] "2018-02-18 10:16:16 PST" "2018-02-18 10:16:16 PST"
for(di in d) {
print(di)
}
#> [1] 1518977777
#> [1] 1518977777
Notice we printed numbers, not dates/times. To avoid this problem introduce an index, and loop over that, not over the vector contents.
for(ii in seq_along(d)) {
di <- d[[ii]]
print(di)
}
#> [1] "2018-02-18 10:16:16 PST"
#> [1] "2018-02-18 10:16:16 PST"
Continue reading R Tip: Introduce Indices to Avoid for() Class Loss Issues
drop = FALSE with data.framesdrop = FALSE with data.frames
R base::subset() really that bad?R base::subset() really that bad?
[[ ]] Wherever You Can[[ ]] Wherever You CanR tip: use [[ ]] wherever you can.
In R the [[ ]] is the operator that (when supplied a simple scalar argument) pulls a single element out of lists (and the [ ] operator pulls out sub-lists).
For vectors [[ ]] and [ ] appear to be synonyms (modulo the issue of names). However, for a vector [[ ]] checks that the indexing argument is a scalar, so if you intend to retrieve one element this is a good way of getting an extra check and documenting intent. Also, when writing reusable code you may not always be sure if your code is going to be applied to a vector or list in the future.
It is safer to get into the habit of always using [[ ]] when you intend to retrieve a single element.
Example with lists:
list("a", "b")[1]
#> [[1]]
#> [1] "a"
list("a", "b")[[1]]
#> [1] "a"
Example with vectors:
c("a", "b")[1]
#> [1] "a"
c("a", "b")[[1]]
#> [1] "a"
The idea is: in situations where both [ ] and [[ ]] apply we rarely see [[ ]] being the worse choice.
Note on this article series.
This R tips series is short simple notes on R best practices, and additional packaged tools. The intent is to show both how to perform common tasks, and how to avoid common pitfalls. I hope to share about 20 of these about every other day to learn from the community which issues resonate and to also introduce some of features from some of our packages. It is an opinionated series and will sometimes touch on coding style, and also try to showcase appropriate Win-Vector LLC R tools.