Names-values.Rmd

# Names and values

```{r Names-values-1, include = FALSE}
source("common.R")
```

Loading the needed libraries:

```{r Names-values-2, warning=FALSE, message=FALSE}
library(lobstr)
```

## Binding basics (Exercise 2.2.2)

---

**Q1.** Explain the relationship between `a`, `b`, `c` and `d` in the following code:

```{r Names-values-3}
a <- 1:10
b <- a
c <- b
d <- 1:10
```

**A1.** The names (`a`, `b`, and `c`) have same values and point to the same object in memory, as can be seen by their identical memory addresses:

```{r Names-values-4}
obj_addrs <- obj_addrs(list(a, b, c))
unique(obj_addrs)
```

Except `d`, which is a different object, even if it has the same value as `a`, `b`, and `c`:

```{r Names-values-5}
obj_addr(d)
```

---

**Q2.** The following code accesses the mean function in multiple ways. Do they all point to the same underlying function object? Verify this with `lobstr::obj_addr()`.

```{r Names-values-6, eval = FALSE}
mean
base::mean
get("mean")
evalq(mean)
match.fun("mean")
```

**A2.** All listed function calls point to the same underlying function object in memory, as shown by this object's memory address:

```{r Names-values-7}
obj_addrs <- obj_addrs(list(
  mean,
  base::mean,
  get("mean"),
  evalq(mean),
  match.fun("mean")
))

unique(obj_addrs)
```

---

**Q3.** By default, base R data import functions, like `read.csv()`, will automatically convert non-syntactic names to syntactic ones. Why might this be problematic? What option allows you to suppress this behaviour?

**A3.** The conversion of non-syntactic names to syntactic ones can sometimes corrupt the data. Some datasets may require non-syntactic names.

To suppress this behavior, one can set `check.names = FALSE`.

---

**Q4.** What rules does `make.names()` use to convert non-syntactic names into syntactic ones?

**A4.** `make.names()` uses following rules to convert non-syntactic names into syntactic ones:

- it prepends non-syntactic names with `X`
- it converts invalid characters (like `@`) to `.`
- it adds a `.` as a suffix if the name is a [reserved keyword](https://stat.ethz.ch/R-manual/R-devel/library/base/html/Reserved.html)

```{r Names-values-8}
make.names(c("123abc", "@me", "_yu", "  gh", "else"))
```

---

**Q5.** I slightly simplified the rules that govern syntactic names. Why is `.123e1` not a syntactic name? Read `?make.names` for the full details.

**A5.** `.123e1` is not a syntacti name because it is parsed as a number, and not as a string:

```{r Names-values-9}
typeof(.123e1)
```

And as the docs mention (emphasis mine):

> A syntactically valid name consists of letters, numbers and the dot or underline characters and starts with a letter or **the dot not followed by a number**.

---

## Copy-on-modify (Exercise 2.3.6)

---

**Q1.** Why is `tracemem(1:10)` not useful?

**A1.** `tracemem()` traces copying of objects in R. For example:

```{r Names-values-10}
x <- 1:10

tracemem(x)

x <- x + 1

untracemem(x)
```

But since the object created in memory by `1:10` is not assigned a name, it can't be addressed or modified from R, and so there is nothing to trace. 

```{r Names-values-11}
obj_addr(1:10)

tracemem(1:10)
```

---

**Q2.** Explain why `tracemem()` shows two copies when you run this code. Hint: carefully look at the difference between this code and the code shown earlier in the section.

```{r Names-values-12, results = FALSE}
x <- c(1L, 2L, 3L)
tracemem(x)

x[[3]] <- 4
untracemem(x)
```

**A2.** This is because the initial atomic vector is of type `integer`, but `4` (and not `4L`) is of type `double`. This is why a new copy is created.

```{r Names-values-13}
x <- c(1L, 2L, 3L)
typeof(x)
tracemem(x)

x[[3]] <- 4
untracemem(x)

typeof(x)
```

Trying with an integer should not create another copy:

```{r Names-values-14}
x <- c(1L, 2L, 3L)
typeof(x)
tracemem(x)

x[[3]] <- 4L
untracemem(x)

typeof(x)
```

To understand why this still produces a copy, here is an explanation from the [official solutions manual](https://advanced-r-solutions.rbind.io/names-and-values.html#copy-on-modify):

> Please be aware that running this code in RStudio will result in additional copies because of the reference from the environment pane.

---

**Q3.** Sketch out the relationship between the following objects:

```{r Names-values-15}
a <- 1:10
b <- list(a, a)
c <- list(b, a, 1:10)
```

**A3.** We can understand the relationship between these objects by looking at their memory addresses:

```{r Names-values-16}
a <- 1:10
b <- list(a, a)
c <- list(b, a, 1:10)

ref(a)

ref(b)

ref(c)
```

Here is what we learn:

- The name `a` references object `1:10` in the memory.
- The name `b` is bound to a list of two references to the memory address of `a`.
- The name `c` is also bound to a list of references to `a` and `b`, and `1:10` object (not bound to any name).

---

**Q4.** What happens when you run this code?

```{r Names-values-17, eval=FALSE}
x <- list(1:10)
x[[2]] <- x
```

Draw a picture.

**A4.**

```{r Names-values-18}
x <- list(1:10)
x
obj_addr(x)

x[[2]] <- x
x
obj_addr(x)

ref(x)
```

I don't have access to OmniGraffle software, so I am including here the figure from the [official solution manual](https://advanced-r-solutions.rbind.io/names-and-values.html#copy-on-modify):

```{r Names-values-19, echo=FALSE, out.width='180pt', eval=!knitr::is_latex_output()}
knitr::include_graphics("https://raw.githubusercontent.com/Tazinho/Advanced-R-Solutions/main/images/names_values/copy_on_modify_fig2.png", auto_pdf = TRUE)
```

---

## Object size (Exercise 2.4.1) 

---

**Q1.** In the following example, why are `object.size(y)` and `obj_size(y)` so radically different? Consult the documentation of `object.size()`.

```{r Names-values-20, eval=FALSE}
y <- rep(list(runif(1e4)), 100)

object.size(y)
obj_size(y)
```

**A1.** As mentioned in the docs for `object.size()`:

> This function...does not detect if elements of a list are shared.

This is why the sizes are so different:

```{r Names-values-21}
y <- rep(list(runif(1e4)), 100)

object.size(y)

obj_size(y)
```

---

**Q2.**  Take the following list. Why is its size somewhat misleading?

```{r Names-values-22, eval=FALSE}
funs <- list(mean, sd, var)
obj_size(funs)
```

**A2.** These functions are not externally created objects in R, but are always available as part of base packages, so doesn't make much sense to measure their size because they are never going to be *not* available.

```{r Names-values-23}
funs <- list(mean, sd, var)
obj_size(funs)
```

---

**Q3.** Predict the output of the following code:

```{r Names-values-24, eval = FALSE}
a <- runif(1e6)
obj_size(a)

b <- list(a, a)
obj_size(b)
obj_size(a, b)

b[[1]][[1]] <- 10
obj_size(b)
obj_size(a, b)

b[[2]][[1]] <- 10
obj_size(b)
obj_size(a, b)
```

**A3.** Correctly predicted 😉

```{r Names-values-25}
a <- runif(1e6)
obj_size(a)

b <- list(a, a)
obj_size(b)
obj_size(a, b)

b[[1]][[1]] <- 10
obj_size(b)
obj_size(a, b)

b[[2]][[1]] <- 10
obj_size(b)
obj_size(a, b)
```

Key pieces of information to keep in mind to make correct predictions:

- Size of empty vector

```{r Names-values-26}
obj_size(double())
```

- Size of a single double: 8 bytes

```{r Names-values-27}
obj_size(double(1))
```

- Copy-on-modify semantics

---

## Modify-in-place (Exercise 2.5.3)

---

**Q1.** Explain why the following code doesn't create a circular list.

```{r Names-values-28, eval = FALSE}
x <- list()
x[[1]] <- x
```

**A1.** Copy-on-modify prevents the creation of a circular list.

```{r Names-values-29}
x <- list()

obj_addr(x)

tracemem(x)

x[[1]] <- x

obj_addr(x[[1]])
```

---

**Q2.** Wrap the two methods for subtracting medians into two functions, then use the 'bench' package to carefully compare their speeds. How does performance change as the number of columns increase?

**A2.** Let's first microbenchmark functions that do and do not create copies for varying lengths of number of columns.

```{r Names-values-30, message=FALSE, warning=FALSE}
library(bench)
library(tidyverse)

generateDataFrame <- function(ncol) {
  as.data.frame(matrix(runif(100 * ncol), nrow = 100))
}

withCopy <- function(ncol) {
  x <- generateDataFrame(ncol)
  medians <- vapply(x, median, numeric(1))

  for (i in seq_along(medians)) {
    x[[i]] <- x[[i]] - medians[[i]]
  }

  return(x)
}

withoutCopy <- function(ncol) {
  x <- generateDataFrame(ncol)
  medians <- vapply(x, median, numeric(1))

  y <- as.list(x)

  for (i in seq_along(medians)) {
    y[[i]] <- y[[i]] - medians[[i]]
  }

  return(y)
}

benchComparison <- function(ncol) {
  bench::mark(
    withCopy(ncol),
    withoutCopy(ncol),
    iterations = 100,
    check = FALSE
  ) %>%
    dplyr::select(expression:total_time)
}

nColList <- list(1, 10, 50, 100, 250, 500, 1000)

names(nColList) <- as.character(nColList)

benchDf <- purrr::map_dfr(
  .x = nColList,
  .f = benchComparison,
  .id = "nColumns"
)
```

Plotting these benchmarks reveals how the performance gets increasingly worse as the number of data frames increases:

```{r Names-values-31}
ggplot(
  benchDf,
  aes(
    x = as.numeric(nColumns),
    y = median,
    group = as.character(expression),
    color = as.character(expression)
  )
) +
  geom_line() +
  labs(
    x = "Number of Columns",
    y = "Median Execution Time (ms)",
    colour = "Type of function"
  )
```

---

**Q3.** What happens if you attempt to use `tracemem()` on an environment?

**A3.** It doesn't work and the documentation for `tracemem()` makes it clear why:

> It is not useful to trace `NULL`, environments, promises, weak references, or external pointer objects, as these are not duplicated

```{r Names-values-32, error=TRUE}
e <- rlang::env(a = 1, b = "3")
tracemem(e)
```

---

## Session information

```{r Names-values-33}
sessioninfo::session_info(include_base = TRUE)
```