Base slaps!

matt-dray.github.io/nhs-r-2023

Matt Dray, October 2023

Polite notice: this is not a flamewar 🔥

• I have some polite notices and you have to respect them because they’re polite.
• This is not about one tool being better than another; it’s not {base} vs {tidyverse} vs {data.table} vs {collapse}, etc. All of us have a common enemy and that is Python.
• Oh wait, I said no flamewars. Actually, the enemy is anyone who doesn’t open their heart to base R. And you’re here listening to me, so you’re a winner.

What is ‘base R’? 🤔

• It’s entirely possible that you already have no idea what I’m talking about.
• Actually, what do we mean by ‘base’ R?
• Well, it’s as it sounds: it’s the functionality that R is equipped with in the ‘base’ installation, when we first install it.
• It’s the functions that R has before we install and attach any packages.

It’s some packages

> (attached <- sessionInfo()$base |> sort())

[1] "base"      "datasets"  "graphics"  "grDevices" "methods"   "stats"    
[7] "utils"    

> extent <- installed.packages(priority = "base") |> row.names()
> setdiff(extent, attached)

[1] "compiler" "grid"     "parallel" "splines"  "stats4"   "tcltk"    "tools"   

• Buuuut it’s marginally more complicated than that.
• Surprise, it’s actually several packages that are automatically installed with R, including one called ‘base’, confusingly.
• Some are automatically attached when you start R. You can see this if you look at sessionInfo().
• You can also use the function search() to confirm that these packages are already attached when you start a new R session.
• Aside: note that you can assign and print all at once if you wrap the whole thing in brackets.
• Some other packages are considered base, but not attached. These have priority ‘base’ when you look at the output of installed.packages().

Basic data handling

> x <- head(mtcars)
> (y <- x[x$wt > 3, c("hp", "cyl")])

                   hp cyl
Hornet 4 Drive    110   6
Hornet Sportabout 175   8
Valiant           105   6

> (y$hp_per_cyl <- round(y$hp / y$cyl))

[1] 18 22 18

> (z <- y[order(-y$hp_per_cyl), ])

                   hp cyl hp_per_cyl
Hornet Sportabout 175   8         22
Hornet 4 Drive    110   6         18
Valiant           105   6         18

> sapply(z, mean)

        hp        cyl hp_per_cyl 
130.000000   6.666667  19.333333 

• Here’s a quick reminder of what some pure, unadulterated R looks like in a contrived example. This isn’t a training session, so I’ll keep this brief.
• Let’s take the head(), the top six rows, of the built-in mtcars dataset as an example data.frame, and assign it to x.
• Then we can use square-bracket notation to ask for certain rows and columns to extract into a new object, called y.
• So, from x, we want wherever the wt (weight) column of the x object has a value greater than 3.
• After the comma, we’re asking for the columns with the names hp (horsepower) and cyl (cylinder count), which we provide in the vector compsoed with the c() (combine/concatenate) function.
• For a new column, we can assign the round()ed value of horsepower over (/) cylinder count to a freshly hp_per_cyl column, declared on the left of the assignment arrow.
• We can order() the data.frame by values of hp_per_cyl, which will be descending due to the minus (-) symbol, and call this object z.
• Finally, some functional programming: to each column of the data.frame z, let’s apply the function mean with sapply(), which simplifies to a vector of results in this case.
• You’ll likely have recognised certain functions in there at very least. Maybe you learnt something new just from this little bit of code.

1. Stability
2. Dependency
3. Modernity

• Regardless of what you think of that style of coding, I want to make three points (and maybe a bonus one) to just remind you why base R is useful and how it may have changed since you last engaged with it.
• First, its incredible stability over time.
• Second, that it can help limit your time spent in ‘dependnecy’ hell.
• Third, that ‘stability’ does not mean ‘unresponsive to the evolving needs of the R community’.
• My conceit here is that R is great, even when unadorned by packages. This is a message for new users, people who are more used to coding with interfaces afforded by packages, and even folks who aren’t actually R users (yet).

1. Stability

• So, first point: stability.
• I want to talk a little about how base R is a great choice for work that needs to be stable and reproducible over time.
• The core language retains so much of what was in the original specifications in 1993 and in the version 1.0 release in 2000.
• Boradly, base code created 10 years ago has a pretty good chance of running today and 10 years from now.
• There’s no version-2-to-version-3 rift as in Python for example.
• If you want a trip down memory lane, I downloaded R version 1.0 and found in there a little file called ‘Y2K’ that explained that ‘we expect R to be Y2K compliant’, lol. There was a time where we couldn’t be sure if code would survive into the 21st Century; yet here were are nearly a quarter of a century later.
• You might be wondering why I’ve chosen this image. Here’s my terrible metaphor: base R is not a dinosaur. It’s more like a horseshoe crab. It’s not extinct. It’s survived all this time. It’s also pretty unassuming and kind of weird. You could introduce a horseshoe crab today to one from a million years ago and they’d be friends I reckon.
• Also, us R users are Milhouse, aren’t we?

2. Dependency

• Okay, next point: dependencies.
• One of R’s greatest strengths is its extensibility. The CRAN repository has about 20,000 packages at the time of speaking. A lot of smart people have written a lot of excellent code so that you don’t have to.
• Whether or not you take on a dependency is up to you and the type of project you’re working on and it.
• But, of course, you should always be aware that packages come and go, functions deprecate, thermodynamics laws apply.
• For some precious projects you may want to think about where you can minimise dependencies and include more base R code so that you can increase the likelihood of successfully re-executing it into the future and on other computers by other people.
• Base R can help you with this.

3. Modernity

• Third point: modernity.
• I don’t think that a lack of change is stubbornness or sticking one’s head in the sand. I would call it measured and considerate.
• I want to talk about how, despite the stability, the language continues to adapt sensibly, listen to its users and embrace modern ways of using R.
• And actually base R has changed in a number of ways, including the use of a base pipe, simplified anonymous function structure and string literals. These are all things that the community of R users has asked for.
• And perhaps more famously, the conversion of the default stringsAsFactors = TRUE to FALSE, perhaps reflecting a change in R from a language of statistics (where character values as factors makes a lot of sense) to a more general-purpose language.
• Of course, there are still opportunities to improve base R. Lots of stuff can come out of the woodwork after 30 years, or as tastes change. Henrik Bengtsson has a GitHub repo to which people can add issues. Each one lists a specific gripe that someone has had with the functioning of the language. For example, out very own Tim Taylor at UKHSA posted about the behaviour of indexing a dataframe to return a single column. By default, a single column is returned as a vector; the user needs to add the argument drop = FALSE to retain the columnar structure. Perhaps that behaviour will updated in the future?

The Modern Base Aesthetic 🧐

|>, _, \(), r"{}"

• I want to focus a little on the changes made to R from version 4. Maybe you haven’t seen some of these.
• For dramatic effect, I’m using the phrase ‘modern base aesthetic’ to describe this ‘new look’ R.
• The ‘pipe’ (%>%)—developed in the {magrittr} package by Stefan Milton-Bache and popularised by the tidyverse—has an implementation now in base R (|>).
• It’s been followed by a placeholder, the underscore (_), to pass an object from the left-hand side of the pipe to the non-first argument on the right-hand side.
• With functional programming you often write functions on the fly without formally declaring them. These are called ‘anonymous’ or ‘lambda’ functions. You used to have to write out the word function, but now you can use this little backslash. Tidyverse has the tilde, even they recommend the new lambda syntax now.
• String handling can generally be a bit tedious, so R can now recognise strings exactly as they’re provided. This is provided through the use of the letter r ahead of the string, which you can translate to ‘raw’.
• I’ll show you a single example that incorporates all these things.

String literals

> paths <- c(
+   r"{C:\nonsense\trash 2021v1.txt}",
+   r"{C:\nonsense\bilge-2020-"new".txt}",
+   r"{C:\nonsense\rubbish2023_final.txt}"
+ )

Pipes and lambdas

> r"(20\d{2})" |> 
+   gregexpr(paths) |> 
+   regmatches(paths, m = _) |> 
+   sapply(\(yr) yr == "2023")

• Task: extract the year from each of these filepaths and return a logical if they match the current year. This is a contrived demo, yes, but I do stuff like this all the time.
• Windows uses a backslash in filepaths. This is bad.
• R reads ‘’ as new line and can’t handle double-quotes in double-quotes, for example, so normally we’d have to escape them with another backslash. (You can see the syntax highlighting on this page is getting confused and is recolouring ‘’, for example!)
• String literals read the literal string. You do it by putting an ‘r’ before the string and then wrap the string inside the quote marks in curly braces, or parentheses.
• Voila, no need to manually go through the whole string to add extra backslashes.
• Take the regular expression for two zero followed by two digits, i.e. a year, then…
• Pass it to the first argument of gregexpr(), the pattern matching function, then…
• Pass it to the not-first ‘m’ argument of regmatches() using the underscore placeholder, then….

String literals

> paths <- c(
+   r"{C:\nonsense\trash 2021v1.txt}",
+   r"{C:\nonsense\bilge-2020-"new".txt}",
+   r"{C:\nonsense\rubbish2023_final.txt}"
+ )

Pipes and lambdas

> r"(20\d{2})" |> 
+   gregexpr(paths) |> 
+   regmatches(paths, m = _) |> 
+   sapply(\(yr) yr == "2023")

• Pass it as the first argument to sapply(), where we’ll apply a function over our list and simplify it to a vector…
• Where the function is declared on the fly using as an ‘anonymous’ or ‘lambda’ function, declared with this simplified backslash construction rather than having to type out the word function.
• You can see that the style of programming that tidyverse users are confident with has made its way into base R. No more endless nesting of functions or hundreds of intermediate objects cluttering the environment.

String literals

> paths <- c(
+   r"{C:\nonsense\trash 2021v1.txt}",
+   r"{C:\nonsense\bilge-2020-"new".txt}",
+   r"{C:\nonsense\rubbish2023_final.txt}"
+ )

Pipes and lambdas

> r"(20\d{2})" |> 
+   gregexpr(paths) |> 
+   regmatches(paths, m = _) |> 
+   sapply(\(yr) yr == "2023")

[1] FALSE FALSE  TRUE

Bonus: base did what? 🙃

locator() in {pixeltrix}

• I want to show you three packages I’ve written for fun that include interesting base R functions.
• The first is the {pixeltrix}, a package for creating blocky pixel art, like you might see on retro videogames.
• It works thanks to locator(), a curious base function that lets you click a point on a plot and have its coordinates returned.
• {pixeltrix} contains a repeat loop, that asks the user to click on a plot with locator(); updates the plot given the click; and then re-asks the user to click until they break the repeat loop.

readline() in {r.oguelike}

• {r.oguelike} mimics an early text-based videogame.
• It uses base R functions to procedurally build a tile-based dungeon, which is stored in a matrix() and queried with which() to identify the locations of characters. The player is @ and the enemy is E. There’s an inventory where gold can be stored, along with apples, a, that restore a health gauge.
• The user can move their character (represented by the @ symbol) by typing into the interactive prompt, which is provided by the base function readline(). The enemy tracks the player.

R_user_dir() in {tamRgo}

• {tamRgo} simulates a cyber pet that lives on your computer and ‘exists’ between R sessions.
• Like a Tamagotchi in R, if you’re the right age to know what a Tamagotchi is.
• How can data about your pet exist between sessions? The package makes use of the base R function R_user_dir(), which builds a path to a standardised location on the user’s computer where data or cached items can be stored. In {tamRgo}, a ‘blueprint’ text file stores the pet’s status. The blueprint is read at the start of the next R session and values related to time, such as the pet’s age and hunger level, are updated given the difference between the current date and date of last interaction.

Base slaps!

Stability, dependency, modernity… oddity!

matt-dray.github.io/nhs-r-2023

Matt Dray

• So, at best: maybe you’ll go back to your computer and consider whether base R might be useful for you in terms of its stability over time, or how in-built functionality might simplify your dependencies. Maybe you’ll give the more modern functionality a go. Or maybe you were just unaware (confused?) that the base installation of R has the flexibility to do some unexpected, creative things.
• You can find these slides at that address, embedded in that QR code, and then you can also see what I’ve been up to by clicking the links there.
• At worst: I hope you learnt at least one new thing, however small.
• At very, very best: I hope you agree with me that base slaps!

Links 🔗

• Slides on the web
• Source code for this talk
• Blogpost about this talk

Credits 👏

• ‘Summer of 4 Ft. 2’, The Simpsons, created by Matt Groening (via Frinkiac)
• ‘Dependency’, xkcd, created by Randall Munroe (CC BY-NC 2.5, altered)
• R logos, R Foundation (CC BY-SA 4.0, altered)