1.6 Advanced issues

This section introduces some more advanced issues:

  • Importing data allows reading data from files or online locations;

  • Factors are variables (vectors) that contain categorical data;

  • Lists are hierarchical (recursive) vectors;

  • Flow control provides a glimpse on conditional statements and loops in R.

As most of these topics are covered in greater detail in later chapters, this section only serves as a brief introduction or “sneak preview”. So do not panic if some of these topics remain a bit puzzling at this point. Essentially, our current goal is only to become familiar with these concepts and distinctions. It is good to be aware of their existence and recognize them later, even when their details remain a bit fuzzy at this stage.

1.6.1 Importing data

In most cases, we do not generate the data that we analyze, but obtain a table of dataset from somewhere else. Typical locations of data include:

  • data included in R packages,
  • data stored on a local or remote hard drive,
  • data stored on online servers.

R and R Studio provide many ways of reading in data from various sources. Which way is suited to a particular dataset depends mostly on the location of the file and the format in which the data is stored. We will examine different ways of importing datasets in Chapter 6. Here, we show the 2 most common ways of importing a dataset.

The dataset we import stems from an article in the Journal of Clinical Psychology (Woodworth, O’Brien-Malone, Diamond, & Schüz, 2017). An influential paper by Seligman et al. (Seligman, Steen, Park, & Peterson, 2005) found that several positive psychology interventions reliably increased happiness and decreased depressive symptoms in a placebo-controlled internet study. Woodworth et al. (2017) re-examined this claim by measuring the long-term effectiveness of different web-based positive psychology interventions and published their data in another article (Woodworth, O’Brien-Malone, Diamond, & Schüz, 2018) (see Appendix B.1 for details).

Data from a file

When loading data that is stored as a file, there are 2 questions to answer:

  • Location: Where is the file stored?
  • Format: In which format is the file stored?

To illustrate how data can be imported from an online source, we store a copy of the participant data from Woodworth et al. (2018) as a text file in CSV (comma-separated-value) format on a web server at http://rpository.com/ds4psy/data/posPsy_participants.csv. Given this setup, we can load the dataset into an R object p_info by evaluating the following command (from the package readr, which is part of the tidyverse):

Note the feedback message provided by the read_csv() function of the readr package: It tells us the names of the variables (columns) that were read and the data type of these variables (here: numeric variables of type “double”). To obtain basic information about the newly created tibble p_info, we can simply evaluate its name:

Data from an R package

An even simpler way of obtaining a data file is available when datasets are stored in and provided by R packages. In this case, some R programmer has typically saved the data in a compressed format (as an .rda file) and it can be accessed by installing and loading the corresponding R package. Provided that we have installed and loaded this package, we can easily access the corresponding dataset. In our case, we need to load the ds4psy package, which contains the participant data as an R object posPsy_p_info. We can treat and manipulate such data objects just like any other R object. For instance, we can copy the dataset posPsy_p_info into another R object by assigning it to p_info_2:

Having loaded the same data in 2 different ways, we should verify that we obtained the same result both times. We can verify that p_info and p_info_2 are equal by using the all.equal command:

Throughout this book, we will primarily rely on the datasets provided by the ds4psy package, but show additional options of importing files stored in different locations and formats in the chapter on Importing data (Chapter 6).

Checking a dataset

To get an initial idea about the contents of a dataset (often called a data frame, table, or tibble), we typically inspect its dimensions, print it, ask for its structure (by using the base R command str), or take a glimpse on its variables and values:

dim(p_info)              # 295 rows, 6 columns
#> [1] 295   6
p_info                   # prints a summary of the table/tibble
#> # A tibble: 295 x 6
#>       id intervention   sex   age  educ income
#>    <dbl>        <dbl> <dbl> <dbl> <dbl>  <dbl>
#>  1     1            4     2    35     5      3
#>  2     2            1     1    59     1      1
#>  3     3            4     1    51     4      3
#>  4     4            3     1    50     5      2
#>  5     5            2     2    58     5      2
#>  6     6            1     1    31     5      1
#>  7     7            3     1    44     5      2
#>  8     8            2     1    57     4      2
#>  9     9            1     1    36     4      3
#> 10    10            2     1    45     4      3
#> # … with 285 more rows
str(p_info)              # shows the structure of an R object
#> tibble [295 × 6] (S3: spec_tbl_df/tbl_df/tbl/data.frame)
#>  $ id          : num [1:295] 1 2 3 4 5 6 7 8 9 10 ...
#>  $ intervention: num [1:295] 4 1 4 3 2 1 3 2 1 2 ...
#>  $ sex         : num [1:295] 2 1 1 1 2 1 1 1 1 1 ...
#>  $ age         : num [1:295] 35 59 51 50 58 31 44 57 36 45 ...
#>  $ educ        : num [1:295] 5 1 4 5 5 5 5 4 4 4 ...
#>  $ income      : num [1:295] 3 1 3 2 2 1 2 2 3 3 ...
#>  - attr(*, "spec")=
#>   .. cols(
#>   ..   id = col_double(),
#>   ..   intervention = col_double(),
#>   ..   sex = col_double(),
#>   ..   age = col_double(),
#>   ..   educ = col_double(),
#>   ..   income = col_double()
#>   .. )
tibble::glimpse(p_info)  # shows the types and initial values of all variables (columns)
#> Rows: 295
#> Columns: 6
#> $ id           <dbl> 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 1…
#> $ intervention <dbl> 4, 1, 4, 3, 2, 1, 3, 2, 1, 2, 2, 2, 4, 4, 4, 4, 3, 2, 1,…
#> $ sex          <dbl> 2, 1, 1, 1, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2, 1, 1, 1, 1,…
#> $ age          <dbl> 35, 59, 51, 50, 58, 31, 44, 57, 36, 45, 56, 46, 34, 41, …
#> $ educ         <dbl> 5, 1, 4, 5, 5, 5, 5, 4, 4, 4, 5, 4, 5, 1, 2, 1, 4, 5, 3,…
#> $ income       <dbl> 3, 1, 3, 2, 2, 1, 2, 2, 3, 3, 1, 3, 3, 2, 2, 1, 2, 2, 1,…

Understanding a dataset

When analyzing a data file from a remote source, it is crucial to also obtain a description of the variables and values contained in the file (often called a Codebook). For the dataset loaded into p_info this description looks as follows:

posPsy_participants.csv contains demographic information of 295 participants:

  • id: participant ID

  • intervention: 3 positive psychology interventions, plus 1 control condition:

    • 1 = “Using signature strengths”,
    • 2 = “Three good things”,
    • 3 = “Gratitude visit”,
    • 4 = “Recording early memories” (control condition).
  • sex:

    • 1 = female,
    • 2 = male.
  • age: participant’s age (in years).

  • educ: level of education:

    • 1 = Less than Year 12,
    • 2 = Year 12,
    • 3 = Vocational training,
    • 4 = Bachelor’s degree,
    • 5 = Postgraduate degree.
  • income:

    • 1 = below average,
    • 2 = average,
    • 3 = above average.

Beyond conveniently loading datasets, another advantage of using data provided by R packages is that the details of a dataset are easily accessible by using the standard R help system. For instance, provided that the ds4psy package is installed and loaded, we can obtain the codebook and background information of the posPsy_p_info data by evaluating ?posPsy_p_info.


  1. Using the data in p_info, create a new variable uni_degree that is TRUE if and only if a person has a Bachelor’s or Postgraduate degree.

  2. Use R commands to obtain (the row data of) the youngest person with a university degree.

We will examine this data file further in Exercise 8 (see Section 1.8.8).

1.6.2 Factors

Whenever creating a new vector or a table with several variables (i.e., a data frame or tibble), we need to ask ourselves whether the variable(s) containing character strings or numeric values are to be considered as factors. A factor is a categorical variable (i.e., a vector or column in a data frame) that distinguishes between different levels of a variable and sorts these levels in some order.

stringsAsFactors = FALSE

Let’s revisit our example of creating a data frame df from the four vectors name, gender, age, and height (see Section 1.5.2). The columns of this table were originally provided as vectors of type “character”. In many cases, character variables simply contain text data that we do not want to treat as factors. When we want to prevent R from converting character variables into factors when creating a new data frame, we can explicitly set an option stringsAsFactors = FALSE in the data.frame() command:

Let’s inspect the resulting gender variable of df:

This shows that the variable df$gender is a vector of type “character”, rather than a factor. In fact, df$gender is equal to gender, as the original vector also was of type “character”.

stringsAsFactors = TRUE

Up to R version 4.0.0 (released on 2020-04-24), the default setting of the data.frame() function was stringsAsFactors = TRUE. Thus, when creating the data frame df above, the variables consisting of character strings (here: name and gender) were — to the horror of generations of students — automatically converted into factors.15 We can still re-create the previous default behavior by setting stringsAsFactors = TRUE:

In this data frame df, all character variables were converted into factors. When inspecting a factor variable, its levels are printed by their text labels. But when looking closely at the output of df$gender, we see that the labels male and female are not quoted (as the text elements in a character variable would be) and the factor levels are printed below the vector.

Factors are similar to character variables insofar as they identify cases by a text label. However, the different factor values are internally saved as integer values that are mapped to the different values of the character variable in a particular order (here: alphabetically). The unclass() command shows that the variable names of df are internally saved as integers from 1 to 7 (with the original names as labels of the seven factor levels). Similarly, the gender variable of df contains only integer values of 1 and 2, with 1 corresponding to “female” and 2 corresponding to “male”.

Importantly, a factor value denotes solely the identity of a particular factor level, rather than its magnitude. For instance, elements with an internal value of 2 (here: “male”) are different from those with a value of 1 (here: “female”), but not larger or twice as large.

To examine the differences between factors and character variables, we can use the as.character() and as.factor() functions to switch factors into characters and vice versa.

as.character() turns factors into character variables

Using the as.character() function on a factor and assigning the result to the same variable turns a factor into a character variable:

We see that using the as.character() function on the factor df$gender created a character variable. Each element of the character variable is printed in quotation marks (i.e., "female" vs. "male").

as.factor() turns character variables into factors

When now using the function as.factor() on a character variable, we turn the character string variable into a factor. Internally, this changes the variable in several ways: Each distinct character value is turned into a particular factor level, the levels are sorted (here: alphabetically), and the levels are mapped to an underlying numeric representation (here: consecutive integer values, starting at 1):

Thus, using as.factor() on a character variable created a factor that is internally represented as integer values. When printing the variable, its levels are identified by the factor labels, but not printed in quotation marks (i.e., female vs. male).

factor() defines factor variables with levels

Suppose we knew not only the current age, but also the exact date of birth (DOB) of the people in df:

Table 1.1: Data frame df with an additional DOB variable.
name gender age height DOB
Adam male 21 165 1999-01-01
Bertha female 23 170 1997-05-23
Cecily female 22 168 1998-02-11
Dora female 19 172 2001-08-09
Eve female 21 158 1998-09-28
Nero male 18 185 2001-11-04
Zeno male 24 182 1995-10-25

The new variable df$DOB (i.e., a column of df) is of type “Date”, which is another type of data that we will encounter in detail in Chapter 10 on Dates and times. A nice feature of date and time variables is that they can be used to extract date- and time-related elements, like the names of months and weekdays. For the DOB values of df, the corresponding variables month and wday are as follows:

Table 1.2: Data frame df with month and wday of the DOB variable.
name gender age height DOB month wday
Adam male 21 165 1999-01-01 Jan Fri
Bertha female 23 170 1997-05-23 May Fri
Cecily female 22 168 1998-02-11 Feb Wed
Dora female 19 172 2001-08-09 Aug Thu
Eve female 21 158 1998-09-28 Sep Mon
Nero male 18 185 2001-11-04 Nov Sun
Zeno male 24 182 1995-10-25 Oct Wed

The two new variables df$month and df$wday presently are character vectors:

If we ever wanted to categorize people by the month or weekday on which they were born or create a visualization that used the names of months or weekdays as an axis, it would make more sense to define these variables as factors. However, simply using as.factor() on the columns of df would fall short:

The resulting vectors would be factors, but their levels are incomplete (as not all months and weekdays were present in the data) and would be sorted in alphabetical order (e.g., the month of “Apr” would precede “Feb”).

The factor() function allows defining a factor variable from scratch. As must factors can assume a fixed number of levels, the function contains an argument levels to provide the possible factor levels (as a character vector):

As we explicitly defined all_months and all_wdays (as character vectors) and specified them as the levels of the factor() function, the resulting vectors are factors that know about values that did not occur in the data. At this point, the factor levels are listed in a specific order, but are only considered to be different from each other. If we explicitly wanted to express that the levels are ordered, we can set the argument ordered to TRUE:

Thus, if we wanted to convert the variables month and wday of df into ordered factors, we would need to re-assign them as follows:

Appearance vs. representation

We just encoded the character variables month and wday of a data frame df as ordered factors. However, the resulting data frame df looks and prints as it did before:

Table 1.3: Data frame df with month and wday as ordered factors.
name gender age height DOB month wday
Adam male 21 165 1999-01-01 Jan Fri
Bertha female 23 170 1997-05-23 May Fri
Cecily female 22 168 1998-02-11 Feb Wed
Dora female 19 172 2001-08-09 Aug Thu
Eve female 21 158 1998-09-28 Sep Mon
Nero male 18 185 2001-11-04 Nov Sun
Zeno male 24 182 1995-10-25 Oct Wed

Thus, defining the character variables month and wday of df as ordered factors affects how these variables are represented and treated by R functions, but not necessarily how they appear. The difference between the properties of an underlying representation and its (often indiscriminate and possibly deceptive) appearance on the surface is an important aspect of representations that will pop up repeatedly throughout this book and course.

Note that turning variables into factors affects what we can do with them. For instance, if month or wday were numeric variables, we could use them for arithmetic comparisons and indexing, like:

As these variables are factors, however, these statements yield NA values.

as.numeric() turns factor levels into numbers, but…

We could fix this by using the as.numeric() function for converting factor levels into numbers:

This seems to work, but requires that we are aware how the factor levels were defined (e.g., that the 7th level of wday corresponded to Sunday). As it is easy to make mistakes when interpreting factors as numbers, we should always check and double check the result of such conversions. Actually, converting factor levels into numbers is often a sign that a variable should not have been encoded as a factor.

The subtle, but profound lesson here is that variables that may appear the same (e.g., when printing a variable or inspecting a data table) may still differ in important ways. Crucially, the type and status of a variable affects what can be done with it and how it is treated by R commands. For instance, asking for summary() on a factor yields a case count for each factor level (including levels without any cases):

By contrast, calling summary() on the corresponding numeric variables yields descriptive statistics of its numbers:

and a summary() of the corresponding character variables merely describes the vector of text labels:

Thus, even when variables may look the same when inspecting the data, it really matters how they are internally represented. In factors, the difference between a variable’s appearance and its underlying representation is further complicated by the option to supply a label (as a character object) for each factor level. Unless there are good reasons for an additional layer of abstraction (e.g., for labeling groups in a graph), we recommend only defining factor levels.

At this point, we do not need to understand the details of factors. But as factors occasionally appear accidentally — as stringsAsFactors = TRUE was the default for many decades, until it was changed in R 4.0.0 (on 2020-04-24)16 — and are useful when analyzing and visualizing empirical data (e.g., for distinguishing between different experimental conditions) it is good to know that factors exist and can be dealt with.


Alternative factors: In many cultures and regions, people consider Sunday to be the first day of a new week, rather than the last day of the previous week.

  1. Define a corresponding ordered factor wday_2 (for the data frame df).

  2. In which ways are the factor variables wday and wday_2 the same or different?

  3. Use both factor variables to identify people born on a Sunday (by vector indexing).


  1. Defining an ordered factor wday_2 (for the data frame df):
  1. Comparing factors wday and wday_2:

All the values of df$wday and df$wday_2 remain the same. However, in wday_2, Sunday (Sun) is now the first factor level, rather than the last:

If the two factor variables were re-interpreted as numbers, their results would no longer be identical (even though the differences are fairly subtle in this example):

  1. Using vector indexing on both factor variables to identify people born on a Sunday:

1.6.3 Lists

Beyond scalars, vectors, and tables, R provides “lists” as yet another shape in which data can be represented.

Defining lists

Lists are sequential data structures in which each element can have an internal structure. Thus, they are similar to vectors (e.g., in having a certain length()), but every element of a list can be a complex (rather than an elementary) object.

We can create a list by applying the list() function to a sequence of elements:

The objects l_1 and l_2 are both lists and contain the same three numeric elements, but differ in the representation’s shape:

  • l_1 is a list with three elements, each of which is a scalar (i.e., vector of length 1).
  • l_2 is a list with two elements. The first is a scalar, but the second is a (numeric) vector (of length 2).

Lists are more flexible, but also more complex than the other data shapes we encountered so far. Unlike atomic vectors, lists can contain a mix of data shapes and types:

The ability to store a mix of data shapes and types in a list allows creating complex representations:

As lists can contain other lists, they can be used to construct arbitrarily complex data structures (like tables or tree-like hierarchies):

Finally, the elements of lists can be named. As with vectors, the names() function is used to both retrieve and assign names:

Inspecting lists

The is.list() function allows checking whether some R object is a list:

but note that lists are also considered to be vectors:

As lists are structured objects, a useful function for inspecting lists is str():

Lists are powerful structures for representing data, but can also easily get complicated. In practice, we will rarely need lists, as vectors and tables are typically sufficient for our purposes. However, as we occasionally will encouter lists (e.g., as the output of statistical functions), it is good to be aware of them and know how to access their elements.

Accessing list elements

Accessing list elements is similar to indexing vectors, but needs to account for an additional layer of complexity. This is achieved by distinguishing between single square brackets (i.e., []) and double square brackets ([[]]):

  • x[i] returns the i-th sub-list of a list x (as a list);

  • x[[i]] removes a level of the hierarchy and returns the i-th element of a list x (as an object).

The distinction between single and double square brackets is important when working with lists:

  • [] always returns a smaller list, whereas
  • [[]] removes a hierarchy level to return list elements.

Thus, what is achieved by [] with vectors is achieved by [[]] with lists. An example illustrates the difference:

For named lists, there is another way of accessing list elements that is similar to accessing the named variables (columns) of a data frame:

  • x$n selects a list element (like [[]]) with the name n.

Importantly, using [[]] and $n both return list elements that can be of various data types and shapes. In the case of l_5, the 2nd element named “two” happens to be a list:

For additional details on lists, as well as helpful analogies and visualizations, see 20.5 Recursive vectors (lists) of r4ds (Wickham & Grolemund, 2017).

Vectors and data frames as lists

Due to their immense flexibility, the data structures used earlier in this chapter can be re-represented as lists. In Sections 1.4.1, we used the analogy of a train with a series of waggons to introduce vectors. The train vector could easily be transformed into a list with 15 elements:

However, this re-representation would only add complexity without a clear benefit. As long as we just want to record the load of each waggon, storing train in the shape of a vector is not only sufficient, but simpler (and typically better) than using a list.

What could justify using a list? Suppose we wanted to store not just the load of each waggon but also its weight. A corresponding list train_ls could look as follows:

The list train_ls contains two vectors: One records the load of each waggon (as a vector with 15 elements, stored as a factor with 3 levels) and the other one records its weight (as a vector with 15 numeric elements).

Does the addition of a second vector justify using a list? Not really. If both vectors have the same length, a simpler (and typically better) way to store this data would be a data frame:

This data frame provides convenient access to each column (i.e., the two variables that were the vectors of the list), each row (i.e., each waggon), and cell (i.e., any combination of a variable and waggon).

Thus, the lesson to be learned here is that lists are flexible, but rarely needed. As long as data is systematic and rectangular, vectors and data frames are sufficient and to be preferred. Not only are simpler data structures typically better, but many R functions are written and optimized for vectors and data frames, rather than lists. As a consequence, lists are only used when data requires mixing data types or the types or shapes of data are so complex, irregular, or unpredictable that they do not fit into a rectangular table.


  1. List features:
  • What is similar for and what distinguishes lists from vectors?

  • What is similar for and what distinguishes lists from tables (data frames/tibbles)?

  1. List access:

Someone makes the following claims about R data structures:

  • “What [] does with vectors is done with [[]] with lists.”
  • “What t$n does with tables is done with l$n with lists.”

Explain what is “what” in both cases and construct an example that illustrates the comparison.


  • The “what” in “What [] does with vectors is done with [[]] with lists.” refers to numeric indexing of vector/list elements.


  • The “what” in “What is done with df$n on tables is done with ls$n with lists.” refers to named indexing (of table columns/list elements).


  1. Lists vs. vectors:
  • Do x <- list(1:3) and y <- list(1, 2, 3) define identical or different objects? Describe both objects in terms of lists and vectors.

  • How can we access and retrieve the element “3” in the objects x and y?

  • How can we change the element “3” in the objects x and y to “4”?


  • Do x <- list(1:3) and y <- list(1, 2, 3) define identical or different objects? Describe both objects in terms of lists and vectors.

Both commands define a list, but two different ones:

- `x`: `list(1:3)` is identical to `list(c(1, 2, 3))` and defines a list with _one_ element, which is the numeric vector `1:3`.  

- `y`: `list(1, 2, 3)` defines a list with _three_ elements, each of which is a numeric scalar (i.e., a vector of length 1). 
  • How can we access and retrieve the element “3” in the objects x and y?
  • How can we change the element “3” in the objects x and y to “4”?
  1. A table vs. list of people:

Take one of the data frames df (describing people) from above (e.g., from Section 1.5.2 and convert it into a list df_ls. Then solve the following tasks for both the table df and the list df_ls:

  • Get the vector of all names.
  • Get the gender of the 3rd and the 6th person.
  • Get the maximum age of all persons.
  • Compute the mean height of all persons.
  • Get all data about Nero.


Converting df into a list df_ls:

  • Get the vector of all names:
  • Get the gender of the 3rd and the 6th person:
  • Get the maximum age of all persons:
  • Compute the mean height of all persons:
  • Get all data for Nero:

We see that accessing variables (in columns) is simple and straightforward for both tables and lists. However, accessing individual records in rows is much easier for tables than for lists — which is why we typically record our data at tables.

1.6.4 Flow control

As we have seen when defining our first scalars or vectors (in Sections 1.3 and 1.4), it matters in which order we define objects. For instance, the following example first defines x as a (numeric) scalar 1, but then re-assigns x to a vector (of type integer) 1:10, before re-assigning x to a scalar (of type character) “oops”:

Although this example may seem trivial, it illustrates 2 important points:

  1. R executes code sequentially: The order in which code statements and assignments are evaluated matters.

  2. Whenever changing an object by re-assigning it, any old content of it (and its type) is lost.

At first, this dependence on evaluation order and the “forgetfulness” of R may seem like a nuisance. However, both features actually have their benefits when programming algorithms that require distinctions between cases or repeated executions of code. We will discuss such cases in our introduction to Programming (see Chapters 11 and 12). But as it is likely that you will encounter examples of if-then statements or loops before getting to these chapters, we briefly mention 2 major ways in which we can control the flow of information here.


A conditional statement in R begins with the keyword if (in combination with some TEST that evaluates to either TRUE or FALSE) and a THEN part that is executed if the test evaluates to TRUE. An optional keyword else and a corresponding ELSE part is executed if the test evaluates to FALSE.

The basic structures of a conditional test in R are the following:

Notice that both if statements involve two different types of parentheses: Whereas the TEST is enclosed in round parentheses (), the THEN and ELSE parts are enclosed in curly brackets {}.


A caveat: Users that come from other statistical software packages (like SAS or SPSS) often recode data by using scores of conditional statements. Although this is possible in R, its vector-based nature and the powers of (logical and numeric) indexing usually provide better solutions.


  • Predict the final outcome of evaluating y in the following code and then evaluate it to check your prediction:

Conditional statements will be covered in greater detail in our chapter on Functions (Chapter 11).


Loops repeat particular lines of code as long as some criteria are met. This can be achieved in several ways, but the most common form of loop is the for loop that increments an index or counter variable (often called i) within a pre-specified range. The basic structure of a for loop in R is the following:

The code in <LOOP-BODY> is executed repeatedly — as often as indicated in <LOOP_RANGE>. The variable i serves as a counter that indicates the current iteration of the loop.


  • Predict the effects of the following loops and then evaluate them to check your prediction:

We will learn more about loops in our chapter on Iteration (Chapter 12).

This concludes our sneak preview on some more advanced aspects of R. Again, do not worry if some of them remain a bit fuzzy at this point — they will re-appear and be explained in greater detail later. Let’s wrap up this chapter and check what we have learned by doing some exercises.


Seligman, M. E., Steen, T. A., Park, N., & Peterson, C. (2005). Positive psychology progress: Empirical validation of interventions. American Psychologist, 60(5), 410. https://doi.org/10.1037/0003-066X.60.5.410

Wickham, H., & Grolemund, G. (2017). R for data science: Import, tidy, transform, visualize, and model data. Retrieved from http://r4ds.had.co.nz

Woodworth, R. J., O’Brien-Malone, A., Diamond, M. R., & Schüz, B. (2017). Web-based positive psychology interventions: A reexamination of effectiveness. Journal of Clinical Psychology, 73(3), 218–232. https://doi.org/10.1002/jclp.22328

Woodworth, R. J., O’Brien-Malone, A., Diamond, M. R., & Schüz, B. (2018). Data from “Web-based positive psychology interventions: A reexamination of effectiveness”. Journal of Open Psychology Data, 6(1). https://doi.org/10.5334/jopd.35

  1. The default value of the argument stringsAsFactors used to be TRUE for decades. As this caused much confusion, the default has now been changed. From R version 4.0.0 (released on 2020-04-24), the default is stringsAsFactors = FALSE. This shows that the R gods at https://cran.r-project.org/ are listening to user feedback, but you should not count on changes happening quickly.

  2. The recent switch from the default of stringsAsFactors = TRUE to stringsAsFactors = FALSE actually teaches us an important lesson about R: Always be aware of defaults and try not to rely on them too much in your own code. Explicating the arguments used in our own functions will protect us from changes in implicit defaults. For background on R’s stringsAsFactors default, see the post stringsAsFactors (by Kurt Hornik, on 2020-02-16) on the R developer blog.