R
Completed
-
Section 1: Getting Started
-
Section 2: Core Syntax
-
Section 3: Data Structures
-
Section 4: Data Manipulation
-
Section 5: Visualization and Statistics
-
Section 6: Advanced R
-
Section 7: Practical Projects
-
Section 8: Interview Practice
-
Section 9: More Practice Exercises
-
Section 10: Shiny Apps in Depth
-
Section 11: More Data Wrangling
-
Section 12: Tidyverse Deep Dive
-
Section 13: Statistical Modeling Deep Dive
-
Section 14: Machine Learning in R
-
Section 15: R Visualization Deep Dive
-
Section 16: R Package Development Deep Dive
-
Section 17: R for Reproducible Research
-
Section 18: R and Databases
-
Section 19: R Performance Optimization
-
Section 20: Bioinformatics and Specialized R
-
Section 21: More Shiny Practice
-
Section 22: More Practice Exercises
-
Section 23: R Data Structures Deep Dive
-
Section 24: More Interview and Review
-
Section 25: R for Business Analytics
-
Section 26: R Text Mining and NLP
-
Section 27: R Spatial Data Analysis
-
Section 28: R Deep Learning
-
Section 29: Advanced Statistical Techniques
-
Section 30: R Object Systems Deep Dive
-
Section 31: R Environments and Metaprogramming
-
Section 32: R for Finance
-
Section 33: R for Clinical and Health Data
-
Section 34: More Shiny Advanced Practice
-
Section 35: R Data Cleaning Deep Dive
-
Section 36: R Reporting Automation
-
Section 37: More Practical Projects Round 2
-
Section 38: R Ecosystem and Career
-
Section 39: More Visualization Practice
-
Section 40: R for Experimentation
-
Section 41: R for Genomics and Bioinformatics Deep Dive
-
Section 42: R for Marketing Analytics
-
Section 43: R Data Import/Export Deep Dive
-
Section 44: R String Processing Deep Dive
-
Section 45: R for Actuarial and Insurance Analytics
-
Section 46: R Testing and Quality Assurance Deep Dive
-
Section 47: R Version Control and Collaboration
-
Section 48: R Advanced Functional Programming
-
Section 49: R for Supply Chain and Operations
-
Section 50: More Practice Exercises Round 3
-
Section 51: R Dashboards and BI Integration
-
Section 52: R Data Governance and Ethics
-
Section 53: More Modeling Practice
-
Section 54: R Final Capstone Projects
-
Section 55: R for Sports Analytics
-
Section 56: More Interview Practice Round 2
-
Section 57: R Networking and APIs
-
Section 58: R for Environmental Science
-
Section 59: R Notebook and Documentation Practices
-
Section 60: More Data Wrangling Mastery
-
Section 61: R for A/B Testing at Scale
-
Section 62: R Package Ecosystem Deep Dive
10: Data Frames
I've noticed a recurring pattern with people moving into R from a pure math or basic programming background: they tend to treat a data.frame as if it's just a two-dimensional matrix. On the surface, they look identical—rows and columns of data. But if you treat them the same way, you're going to run into some frustrating bugs, usually involving your numbers suddenly turning into text.
Thinking a Data Frame is just a Matrix
In a matrix, every single element must be of the same data type. If you try to mix a number and a string in a matrix, R will silently "coerce" everything into the most flexible type (usually a character). I'll show you exactly what I mean.
# This is a matrix. Watch what happens to the numbers.
employee_matrix <- matrix(c("Alice", 75000, "Bob", 82000), ncol = 2)
print(employee_matrix)
# Output:
# [,1] [,2]
# [1,] "Alice" "75000"
# [2,] "Bob" "82000"
Notice those quotes around "75000"? The matrix forced your salaries to become strings. Now, if you try to calculate the average salary using mean(), R will throw an error or return NA because you can't do math on words. This is the "matrix trap."
A Collection of Vectors Disguised as a Table
A data.frame is fundamentally different. Instead of one big block of a single type, think of it as a list of vectors that happen to have the same length. This allows each column to hold its own data type while still behaving like a table.
# This is a data frame. Types are preserved.
employee_df <- data.frame(
name = c("Alice", "Bob"),
salary = c(75000, 82000),
remote = c(TRUE, FALSE)
)
print(employee_df)
# Output:
# name salary remote
# 1 Alice 75000 TRUE
# 2 Bob 82000 FALSE
Now, salary remains a numeric vector and remote remains a logical vector. You can perform math on one column without affecting the others. In my experience, the best way to wrap your head around this is to stop seeing a "grid" and start seeing "columns glued together."
Accessing Your Data Without the Headache
Since a data frame is essentially a list of columns, you have a few ways to get your data out. I personally use the $ operator 90% of the time because it's explicit and readable.
If you want the salaries, you just call employee_df$salary. This returns a simple vector. However, if you need to filter rows or select specific columns by index, you'll use the bracket notation [row, column].
# Get the first row only
first_emp <- employee_df[1, ]
# Get the name of the second employee
second_name <- employee_df[2, "name"]
# Calculate the average salary (this works now!)
avg_sal <- mean(employee_df$salary)
One quick tip: when you use [row, ] (leaving the column blank), R gives you a smaller data frame. When you use $column, R gives you a vector. Keeping that distinction clear in your mind will save you hours of debugging when you start building more complex models.
📋 Practical Task
Building a Local Coffee Shop Inventory
You need to organize a small inventory list for a coffee shop. Your goal is to create a data frame that handles different data types correctly and then extract specific information from it.
Requirements:
- Create a data frame named
coffee_inventorywith three columns:item(character): "Espresso", "Latte", "Cappuccino"price(numeric): 2.50, 3.75, 3.50in_stock(logical): TRUE, TRUE, FALSE
- Using the
$operator, calculate the average price of the items. - Using bracket notation
[row, col], extract theitemname of the third product in the list. - Print both the average price and the third item's name to the console.
There are no comments for now.