dplyr Package in R: Syntax, Core Verbs, and Research Workflow Guide

The dplyr package in R is a data manipulation library within the tidyverse providing a grammar-based syntax for transforming, subsetting, and summarizing research datasets. By replacing Base R bracket indexing with verbs—including filter(), select(), mutate(), summarise(), and arrange()—paired with the native pipe (|>), dplyr creates transparent, auditable, and reproducible scientific data pipelines across in-memory data frames and database backends.

What it is used for in research

Data cleaning, cohort preparation, and variable derivation represent the largest time investment in quantitative empirical research. Across epidemiology, clinical trials, econometrics, bioinformatics, and social sciences, raw experimental and observational data arrive with irregular structures, missing values, inconsistent variable names, and disparate metadata files. The dplyr package in R establishes an explicit, declarative “grammar of data manipulation” that prioritizes human readability, computational consistency, and pipeline reproducibility.

In traditional Base R programming, data transformation relies on matrix-style square-bracket indexing (such as df[df$age >= 18 & !is.na(df$age), c("id", "score")]), nested function calls, and the proliferation of intermediate object assignments (such as temp_df1, temp_df2, and temp_df_final). This imperative scripting approach frequently introduces subtle bugs: row-name conversions can alter indices, intermediate data frame copies consume excessive memory, and complex nested code becomes difficult for independent peer reviewers or lab collaborators to audit. In contrast, dplyr standardizes data manipulation around a coherent set of core verbs, where every function accepts a data frame or tibble as its first argument and consistently returns a transformed data frame or tibble.

When combined with the native R pipe operator (|>, introduced in R 4.1.0) or the magrittr pipe (%>%), dplyr allows researchers to express data workflows as linear, readable sequences of analytical transformations. Rather than reading nested code from the inside out, an investigator reads the pipeline from top to bottom, mirroring the operational logic of the study protocol. For example, a researcher can ingest raw patient records, filter for eligible trial participants, select primary outcome measures, compute baseline covariates, aggregate summary metrics across treatment arms, and pass clean tables directly to statistical modeling functions, such as calculating a correlation matrix in R or conducting a Student t-test vs chi-square analysis.

Beyond clean syntax, dplyr enforces strict semantic discipline in research pipelines. In modern dplyr (versions 1.1.0 through 1.2.1), operations can be evaluated across subgroups using the per-operation .by argument, avoiding the stateful side effects of persistent grouping attributes that historically caused un-grouped analyses to inherit grouping restrictions silently. Furthermore, dplyr’s architecture separates the user-facing grammar from the underlying execution engine. Through companion packages such as dbplyr (for PostgreSQL, SQLite, Snowflake, and DuckDB), dtplyr (for C-optimized data.table speed), and arrow (for multi-gigabyte Apache Parquet files), investigators can author clean dplyr pipelines that execute in-database or out-of-core without rewriting code or sacrificing auditability. The data table below compares these paradigms across computational environments.

Install or access (official source only)

The dplyr package is published on the Comprehensive R Archive Network (CRAN) under the open-source MIT license, maintained by Hadley Wickham and the tidyverse development team. The current production release (version 1.2.1, published April 2026) requires R version 4.1.0 or higher. Researchers should install dplyr exclusively through official CRAN mirrors or authorized institutional package managers to maintain provenance and software supply chain integrity.

To install dplyr as a standalone package from CRAN, execute the following command in an active R console or terminal session:

# Install standalone dplyr from official CRAN mirror
install.packages("dplyr")

Alternatively, researchers whose workflows integrate data visualization with ggplot2, data tidying with tidyr, and string manipulation with stringr can install the complete tidyverse suite, which includes dplyr as a core attached package:

# Install the complete tidyverse ecosystem
install.packages("tidyverse")

During installation, R will automatically resolve, download, and compile or unpack dplyr’s required runtime dependencies. These core imported libraries include cli (command-line formatting), generics (common S3 generics), glue (string interpolation), lifecycle (feature deprecation tracking), magrittr (pipe operators), pillar (colored table formatting), R6 (encapsulated object-oriented programming), rlang (non-standard evaluation and tidy evaluation tools), tibble (modern data frames), tidyselect (backend column selection syntax), and vctrs (vector computation infrastructure).

In enterprise research facilities, high-performance computing (HPC) clusters, and validated clinical development environments, researchers operating behind institutional firewalls or air-gapped systems should configure their repository mirror using Posit Package Manager (PPM) or an internal CRAN snapshot repository to ensure deterministic package builds across all project team members. Once installed, verify the installation and load the package into your R session:

# Load dplyr into the active R environment
library(dplyr)

# Verify installed release version
packageVersion("dplyr")

Step-by-step task (numbered, with menu names or commands exactly as in the current docs)

This worked research task demonstrates an end-to-end clinical observational cohort data preparation pipeline using official dplyr syntax. The objective is to import raw participant visit records, subset and rename experimental variables, apply clinical eligibility filtering criteria, derive new biometric parameters using conditional logic, compute summary outcome metrics by treatment arm, and merge demographic metadata safely without row inflation.

1. Step 1: Ingest and inspect raw tabular cohort data
   Convert the raw data frame to an enhanced tibble structure and inspect column structures, dimensions, and data types using glimpse(). This diagnostic command reveals variable types without truncating column names across console borders:

   # Load required packages
   library(dplyr)
   
   # Illustrative cohort dataset
   set.seed(42)
   raw_cohort <- data.frame(
     sub_id = sprintf("SUBJ-%03d", 1:12),
     site = rep(c("Site_A", "Site_B"), each = 6),
     arm = rep(c("Control", "Active_10mg", "Active_20mg"), times = 4),
     age_yrs = c(45, 62, 38, 71, 54, 29, 66, 50, 48, 73, 59, 34),
     height_cm = c(175, 180, 162, 168, 172, 185, 160, 178, 169, 174, 181, 165),
     weight_kg = c(78, 92, 58, 84, 76, 88, 65, 82, 70, 95, 80, 60),
     sbp_baseline = c(128, 142, 118, 155, 134, 122, 148, 130, 126, 160, 138, 120),
     sbp_followup = c(124, 132, 115, 138, 126, 120, 135, 122, 122, 142, 128, 118),
     adverse_event = c(0, 1, 0, 1, 0, 0, 1, 0, 0, 1, 0, 0),
     protocol_adherent = c(TRUE, TRUE, TRUE, FALSE, TRUE, TRUE, TRUE, TRUE, TRUE, FALSE, TRUE, TRUE),
     stringsAsFactors = FALSE
   )
   
   # Convert to tibble and inspect structure
   cohort_tbl <- as_tibble(raw_cohort)
   glimpse(cohort_tbl)

2. Step 2: Select and rename analytical variables with tidyselect
   Use select() to retain only variables relevant to the statistical analysis plan, standardizing column identifiers into clear snake_case names using new_name = old_name syntax. Leverage tidyselect helper functions (such as starts_with() or where()) to dynamically target related measurement variables:

   # Select, rename, and reorder clinical measurements
   selected_cohort 
     select(
       patient_id = sub_id,
       study_site = site,
       treatment_arm = arm,
       age = age_yrs,
       height_cm,
       weight_kg,
       starts_with("sbp_"),
       adverse_event,
       protocol_adherent
     )
   
   glimpse(selected_cohort)

3. Step 3: Filter participant records with explicit eligibility and missingness rules
   Apply cohort inclusion and exclusion criteria using filter(). In empirical research, boolean logic must account for R’s missing value behavior: if a condition evaluates to NA, filter() drops the row silently. Combine eligibility criteria using comma-separated predicates (which act as logical ANDs) and guard against missing data:

   # Filter for per-protocol participants meeting age and adherence criteria
   eligible_cohort 
     filter(
       !is.na(age),
       age >= 30,
       age <= 75,
       protocol_adherent == TRUE,
       !is.na(sbp_baseline),
       !is.na(sbp_followup)
     )
   
   # Verify retained cohort sample size
   cat("Eligible cohort sample size:", nrow(eligible_cohort), "
   ")

4. Step 4: Compute derived clinical variables using mutate and conditional logic
   Use mutate() to compute body mass index (BMI), systolic blood pressure reduction, and clinical response classification. Use modern case_when() syntax with the official .default parameter (which replaces legacy TRUE ~ fallback syntax) to categorize continuous measurements into discrete clinical stages:

   # Compute derived covariates and clinical categories
   derived_cohort 
     mutate(
       # Compute BMI (weight in kg divided by height in meters squared)
       bmi = weight_kg / ((height_cm / 100) ^ 2),
       # Compute systolic blood pressure reduction (baseline minus followup)
       sbp_delta = sbp_baseline - sbp_followup,
       # Categorize clinical blood pressure response using modern case_when
       response_category = case_when(
         sbp_delta >= 15 ~ "Major Responder",
         sbp_delta >= 5 & sbp_delta  0 & sbp_delta  select(patient_id, treatment_arm, response_category, sbp_delta, bmi))

5. Step 5: Calculate subgroup summary statistics using per-operation grouping
   Aggregate outcome measures across experimental arms using summarise(). Rather than invoking stateful group_by() followed by ungroup(), use the modern .by argument to compute group summaries without altering the persistent grouping structure of the resulting table:

   # Calculate treatment arm summary statistics using transient .by grouping
   arm_summary 
     summarise(
       n_evaluable = n(),
       mean_age = mean(age, na.rm = TRUE),
       mean_baseline_sbp = mean(sbp_baseline, na.rm = TRUE),
       mean_sbp_reduction = mean(sbp_delta, na.rm = TRUE),
       sd_sbp_reduction = sd(sbp_delta, na.rm = TRUE),
       se_sbp_reduction = sd(sbp_delta, na.rm = TRUE) / sqrt(n()),
       ae_rate = mean(adverse_event, na.rm = TRUE) * 100,
       .by = treatment_arm
     )
   
   print(arm_summary)

6. Step 6: Safely merge supplementary metadata using join_by and relationship controls
   Merge external clinical laboratory data into the cohort using left_join(). Modern dplyr utilizes the join_by() function to declare join keys and enforces relationship cardinality (such as relationship = "many-to-one" or "one-to-one"). This defensive check immediately flags unintended Cartesian duplications if secondary keys contain unexpected duplicate entries:

   # Supplementary laboratory metadata table
   lab_metadata <- data.frame(
     study_site = c("Site_A", "Site_B"),
     site_coordinator = c("Dr. Smith", "Dr. Johnson"),
     accreditation_status = c("ISO-15189", "CAP-Accredited"),
     stringsAsFactors = FALSE
   )
   
   # Relational join with explicit cardinality verification
   annotated_cohort 
     left_join(
       lab_metadata,
       by = join_by(study_site),
       relationship = "many-to-one"
     )
   
   glimpse(annotated_cohort)

7. Step 7: Sort and arrange study tables for reporting and export
   Order the final participant data using arrange(), combining ascending factor levels with descending numerical outcomes via desc():

   # Sort final analytical cohort for manuscript presentation
   final_analysis_cohort 
     arrange(treatment_arm, desc(sbp_delta))
   
   # Display top records
   print(head(final_analysis_cohort, n = 5))

Output and how to read it

Executing dplyr functions returns either an enhanced data frame known as a tibble (class tbl_df, tbl, data.frame) or a standard data.frame if the input was not converted. Understanding how to interpret the console output of a tibble is critical for verifying data integrity and identifying unexpected data transformations during research analysis.

When printed in an interactive R console, a tibble generates a structured header, followed by column headers with explicit type tags, the first 10 rows of data, and an informative footer summarizing truncated dimensions. Consider the console output generated by the participant cohort pipeline above:

# A tibble: 10 x 14
   patient_id study_site treatment_arm response_category    bmi   age height_cm weight_kg sbp_baseline
   [chr]      [chr]      [chr]         [chr]              [dbl] [dbl]     [dbl]     [dbl]        [dbl]
 1 SUBJ-001   Site_A     Control       Minimal Responder   25.5    45       175        78          128
 2 SUBJ-002   Site_A     Active_10mg   Moderate Responder  28.4    62       180        92          142
 3 SUBJ-003   Site_A     Active_20mg   Minimal Responder   22.1    38       162        58          118
 4 SUBJ-005   Site_A     Active_10mg   Moderate Responder  25.7    54       172        76          134
 5 SUBJ-006   Site_A     Active_20mg   Minimal Responder   25.7    29       185        88          122
 6 SUBJ-007   Site_B     Control       Moderate Responder  25.4    66       160        65          148
 7 SUBJ-008   Site_B     Active_10mg   Moderate Responder  25.9    50       178        82          130
 8 SUBJ-009   Site_B     Active_20mg   Minimal Responder   24.5    48       169        70          126
 9 SUBJ-011   Site_B     Active_10mg   Moderate Responder  24.4    59       181        80          138
10 SUBJ-012   Site_B     Active_20mg   Minimal Responder   22.0    34       165        60          120
# ℹ 4 more variables: sbp_followup [dbl], sbp_delta [dbl], adverse_event [dbl],
#   site_coordinator [chr], accreditation_status [chr]

Each component of this output conveys precise technical information:

• Header dimension line: The top line (# A tibble: 10 x 14) indicates the total number of rows and columns in the active object. In this case, 10 eligible participant records met all inclusion criteria across 14 measured or derived variables.
• Column type abbreviations: Directly underneath each variable name, dplyr displays abbreviated data types enclosed in angle brackets:
  • [chr]: Character vector (strings, categorical labels, participant identifiers).
  • [dbl]: Double-precision floating point numeric vector (continuous measurements such as BMI, age, and blood pressure).
  • [int]: 32-bit integer vector (discrete counts or coded indicator variables).
  • [fct]: Categorical factor with predefined level metadata.
  • [lgl]: Logical boolean vector containing TRUE, FALSE, or NA.
  • [dttm] or [date]: POSIXct date-time or Date calendar objects.
• Display row budgeting: Tibbles restrict output to the first 10 rows by default to prevent large datasets from flooding the R console or causing terminal latency. To inspect additional rows without writing intermediate files, execute print(df, n = 25) or print(df, n = Inf).
• Column truncation footer: Columns that exceed the horizontal character width of the terminal are omitted from the main grid and enumerated in the footer (e.g., # ℹ 4 more variables: sbp_followup [dbl]...). To force the display of all variables regardless of console width, execute print(df, width = Inf).
• Grouping indicators: When an operation uses the legacy group_by() function instead of .by, the header displays a persistent grouping banner, such as # Groups: treatment_arm [3]. This informs the investigator that subsequent calculations will execute independently across each of the 3 treatment arm subsets. When using modern .by grouping inside summarise() or mutate(), this banner is absent because the output is immediately returned as an ungrouped tibble.

Troubleshooting

Even seasoned quantitative researchers encounter errors and unexpected behaviors when constructing complex data manipulation pipelines. The following diagnostic solutions address the six most common technical issues reported in empirical dplyr research workflows.

1. Masking conflict between stats::filter and dplyr::filter
   Symptom: Calling filter() produces Error in filter(...) : object 'x' not found or throws an unexpected time-series error: 'filter' is only for 'ts' or 'zoo' objects.
   Cause: The Base R stats package, which is loaded automatically in every R session, exports a time-series filtering function named filter(). If another library or script re-attaches stats or loads a package after dplyr, stats::filter() masks dplyr::filter().
   Solution: Disambiguate the namespace by explicitly prefixing the function call as dplyr::filter(...). For project-wide stability, load the conflicted package in your setup script and declare strict preference: conflicted::conflict_prefer("filter", "dplyr") and conflicted::conflict_prefer("lag", "dplyr").

2. Silent row omission from missing values (NA) in filter conditions
   Symptom: Filtering a data frame unexpectedly drops observations where the evaluated variable contains NA, reducing cohort sample size without raising a warning.
   Cause: In R three-valued boolean logic, relational comparisons involving missing data evaluate to missing (e.g., NA > 50 returns NA, not FALSE). The filter() verb retains rows where the predicate expression is strictly TRUE; rows evaluating to FALSE or NA are dropped.
   Solution: If observations with missing values must be preserved for sensitivity analyses or imputation, explicitly include is.na() in your predicate: filter(is.na(biomarker) | biomarker > 50). Conversely, to exclude missing records transparently, write filter(!is.na(biomarker) & biomarker > 50) and document the sample count reduction.

3. Cartesian row inflation during relational joins
   Symptom: Merging two data frames with left_join() or inner_join() produces more rows than existed in the primary table (e.g., merging 500 patient records results in 740 rows).
   Cause: The join key columns in the right-hand dataset contain non-unique duplicate keys. When multiple rows match a single primary key, relational algebra produces a Cartesian cross-product for that key value.
   Solution: Enforce relational cardinality using modern dplyr’s relationship parameter within join_by(): left_join(demographics, by = join_by(patient_id), relationship = "many-to-one"). If duplicate keys exist in the right-hand table, dplyr will halt execution immediately with an explicit error rather than silently distorting cohort statistics.

4. Persistent grouping overhead and unintentional grouped mutations
   Symptom: Subsequent calls to mutate() calculate values within subgroups rather than across the entire dataset, or downstream functions run excessively slowly.
   Cause: Legacy pipelines using group_by() leave the data frame in a persistent grouped state unless explicitly cleared. A subsequent mutate(centered_val = val - mean(val)) will demean within each group rather than across the whole sample.
   Solution: Modern research scripts should replace group_by() with the transient .by argument inside mutate() and summarise() (e.g., summarise(..., .by = group_var)). If legacy group_by() is required, immediately append an explicit ungroup() call at the conclusion of the grouped pipeline step.

5. Deprecation warnings for scoped verbs (mutate_at, summarise_if)
   Symptom: R console outputs Warning: `mutate_at()` was deprecated in dplyr 1.0.0. Please use `across()` instead.
   Cause: Older dplyr tutorials and published scripts relied on scoped verbs (such as mutate_at, mutate_if, mutate_all, summarise_at). These functions have been superseded by the unified across() interface.
   Solution: Refactor scoped operations using across() with tidyselect predicates. For example, rewrite mutate_if(is.numeric, round, 2) to mutate(across(where(is.numeric), (x) round(x, 2))). Note that in dplyr 1.1.0+, using across() inside filter() is also deprecated in favor of if_any() and if_all().

6. Memory exhaustion on datasets exceeding system RAM
   Symptom: Transforming large genomic, spatial, or multi-million-row administrative registries triggers Error: cannot allocate vector of size X Gb or crashes the R session.
   Cause: Base dplyr operations execute entirely in system RAM and may generate memory allocations during sorting, joining, and grouping.
   Solution: Transition memory-heavy workflows to out-of-core backends without abandoning dplyr syntax. For large datasets, use arrow::open_dataset() to query multi-file Parquet archives lazily, utilize dtplyr for memory-efficient C-level data.table execution, or connect to an embedded database using duckdb and dbplyr. The investigator authors standard dplyr verbs, which the backend translates to streaming disk-spilling queries.

Free alternatives (table)

While dplyr is the most widely adopted data manipulation package in the R ecosystem, researchers have access to several high-performance open-source alternatives across R, Python, and SQL databases. Choosing the appropriate data transformation framework depends on dataset volume, memory architecture, dependency management constraints, and team programming environments.

The following table compares open-source data manipulation frameworks commonly utilized in quantitative scientific research:

Software / Package	Primary Ecosystem	Programming Paradigm	Memory and Execution Model	Best Suited For
dplyr	R (Tidyverse)	Declarative verbs with pipe chaining (|>)	In-memory eager evaluation (extensible via backends)	Interactive research analysis, clinical data cleaning, reproducible manuscripts, team pipelines
Base R	R (core)	Imperative indexing ([, $) and functional tools	In-memory, single-threaded, zero external dependencies	Package development requiring zero dependencies, embedded environments, base R scripts
data.table	R	Concise, indexed query syntax (DT[i, j, by])	In-memory with memory reference mutation (in-place modification)	High-performance R computing, massive in-memory datasets (5GB–50GB), genomics, financial time-series
pandas	Python	Object-oriented DataFrame methods and indexing	In-memory, single-threaded eager execution	Python data science stacks, machine learning feature engineering, using query and subset expressions in pandas
Polars	Rust / Python / R	Lazy and eager expressions with query optimization	Multi-threaded, vectorised Apache Arrow memory model	High-throughput computing, multi-core processing; see our detailed Polars vs pandas comparison
DuckDB	C++ / SQL / R / Python	Standard ANSI SQL and relational dataframe API	Columnar vectorised engine with disk-spilling out-of-core execution	Analytical queries on datasets larger than RAM, Parquet data lakes, embedded local data warehousing

For researchers operating in institutional settings with strict IT governance, Base R provides absolute backwards compatibility and zero external dependencies, making it the preferred choice for CRAN package infrastructure and air-gapped production environments. However, Base R code requires significantly more lines of script and lacks standardized error handling across data types.

When working with datasets that approach or exceed system RAM limits (such as whole-genome sequencing registries or electronic health record claims covering tens of millions of encounters), R’s data.table package and the newer Polars engine provide substantial speed advantages through multi-threaded C and Rust execution kernels. Furthermore, researchers collaborating across multidisciplinary teams frequently balance R pipelines against Python workflows or legacy Stata scripts (such as those documented in our guide to executing reproducible Stata code). The companion dataset below provides a structured technical comparison of these tools and their underlying execution characteristics.

Frequently asked questions

What is the difference between dplyr and Base R for data manipulation?

Base R relies on matrix-style square-bracket indexing (such as df[df$status == 1, ]) and standalone functions like subset(), transform(), and aggregate(). In contrast, dplyr provides a structured, grammar-based syntax utilizing explicit verbs (such as filter(), select(), and mutate()) that operate predictably with pipe operators. The dplyr framework prevents accidental dimension-dropping, provides standardized column selection helpers, and offers substantially greater readability for scientific peer review.

Should researchers use the native pipe |> or the magrittr pipe %>% with dplyr?

Modern R research projects should prefer R’s native pipe operator (|>), introduced in R 4.1.0, because it is built directly into the R language kernel, executes with zero package dependency overhead, and provides clearer call-stack traces during debugging. The magrittr pipe (%>%) remains fully supported in dplyr for backwards compatibility and is still required in edge cases involving advanced placeholder syntax (such as . in arbitrary nested function arguments), but the native pipe is the current standard for reproducible data pipelines.

How does the .by argument in dplyr replace group_by() and ungroup()?

In dplyr 1.1.0 and later, functions like mutate(), summarise(), and reframe() support the .by (or by) argument (for example, summarise(mean_val = mean(val), .by = cohort)). This performs calculations across groups transiently for that single operation and immediately returns an ungrouped data frame, eliminating the persistent grouping state caused by group_by() and preventing subtle downstream errors caused by forgotten ungroup() calls.

Why does filter() drop NA values and how can missing data be preserved?

In R, boolean comparisons involving missing values evaluate to NA rather than FALSE (for instance, NA > 10 yields NA). Because filter() retains only rows where the condition evaluates strictly to TRUE, rows with missing values in the evaluated column are dropped by default. To retain missing records explicitly, combine the condition with an is.na() check, such as filter(is.na(score) | score > 10).

How does join_by() prevent duplicate row errors in relational merges?

The join_by() function replaces character vector specifications with direct expression matching and supports explicit cardinality controls via the relationship argument (such as relationship = "many-to-one" or "one-to-one"). If an unanticipated duplicate key in the secondary table would otherwise cause an accidental Cartesian product and inflate row counts, dplyr immediately throws an informative runtime error, protecting cohort integrity.

Can dplyr handle large datasets that exceed computer memory?

Yes. While default dplyr operates in system RAM, its grammar can be translated to out-of-core execution engines without altering pipeline syntax. Researchers can connect dplyr to SQL database tables using dbplyr, query multi-gigabyte Apache Parquet files using the arrow package, or execute vectorised columnar queries using duckdb, enabling seamless scaling to datasets far exceeding available physical memory.

What is the difference between case_when() and case_match() in modern dplyr?

The case_when() function evaluates multiple arbitrary boolean conditions sequentially (such as age >= 65 ~ "Senior", bmi >= 30 ~ "Obese") and accepts a fallback value via .default. In contrast, case_match() is a specialized vectorised switch statement designed to recode specific values of a single target vector (such as case_match(status_code, 1 ~ "Active", 2 ~ "Pending", .default = "Unknown")), providing cleaner syntax when matching discrete categories.

Sources

1. Comprehensive R Archive Network (CRAN). (2026-04-03). Package ‘dplyr’: A Grammar of Data Manipulation (Version 1.2.1). R Foundation for Statistical Computing. https://cran.r-project.org/web/packages/dplyr/index.html. Accessed 2026-11-14.
2. Wickham, H., François, R., Henry, L., Müller, K., and Vaughan, D. (2026). dplyr: A Grammar of Data Manipulation Documentation and Function Reference. Posit Software, PBC. https://dplyr.tidyverse.org/. Accessed 2026-11-14.
3. Wickham, H., Çetinkaya-Rundel, M., and Grolemund, G. (2023). R for Data Science: Import, Tidy, Transform, Visualize, and Model Data (2nd ed.). O’Reilly Media. https://r4ds.hadley.nz/data-transform. Accessed 2026-11-14.
4. Posit Software. (2026). Create, Modify, and Delete Columns: mutate • dplyr. Tidyverse Reference Manual. https://dplyr.tidyverse.org/reference/mutate.html. Accessed 2026-11-14.
5. Posit Software. (2026). Summarise Each Group Down to One Row: summarise • dplyr. Tidyverse Reference Manual. https://dplyr.tidyverse.org/reference/summarise.html. Accessed 2026-11-14.
6. Posit Software. (2026). Apply a Function Across Multiple Columns: across • dplyr. Tidyverse Reference Manual. https://dplyr.tidyverse.org/reference/across.html. Accessed 2026-11-14.
7. Posit Software. (2026). Mutating Joins and join_by Specifications: mutate-joins • dplyr. Tidyverse Reference Manual. https://dplyr.tidyverse.org/reference/mutate-joins.html. Accessed 2026-11-14.
8. Posit Software. (2026). dplyr Changelog and Breaking Release News. Tidyverse Documentation. https://dplyr.tidyverse.org/news/index.html. Accessed 2026-11-14.