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
25: Basic Hypothesis Testing
I've sat through countless code reviews and data presentations where a developer says, "The p-value is 0.03, so there is only a 3% chance that the null hypothesis is true." It sounds confident, but it's fundamentally wrong. This is probably the most common misconception in all of statistics, and if you say it in front of a seasoned data scientist, they will jump on you immediately.
The P-Value is Not the Probability that the Null is True
To see why that logic fails, let's look at a concrete scenario. Imagine you're testing two different versions of a database query to see which one is faster. You have a "Null Hypothesis" ($H_0$): There is no actual difference in speed between Query A and Query B.
# Sample response times in milliseconds
query_a <- c(120, 135, 150, 110, 140)
query_b <- c(145, 160, 155, 150, 170)
# Running a basic t-test
t.test(query_a, query_b)
If R returns a p-value of 0.03, it does not mean there is a 3% chance the queries are the same. The p-value doesn't tell you the probability of the hypothesis; it tells you the probability of the data. Specifically, it says: "Assuming the queries are actually identical in speed, there is a 3% chance I would see a difference this large (or larger) just by random fluke."
Thinking in Terms of Rare Events
The correct way to wrap your head around this is to think of the p-value as a "surprise" index. We assume the null hypothesis is true, and then we look at our results. If the p-value is very low, we're saying, "Wait, if the null were true, this result would be incredibly rare. It's so rare that I'm starting to think the null hypothesis is actually wrong."
In R, the t.test() function is your bread and butter for this. It calculates the t-statistic (the ratio of the difference between groups to the noise in the data) and then maps that to a p-value based on the distribution. I usually tell my mentees to treat the p-value as a trigger for further investigation, not a binary "truth" switch.
Applying the T-Test to Real Data
When you use t.test(), you have a few choices. By default, R performs a Welch Two Sample t-test, which doesn't assume that your two groups have the exact same variance. In the real world, they almost never do, so the default is usually the right call.
# If you suspect the variances are identical, you can specify:
t.test(query_a, query_b, var.equal = TRUE)
# Or, if you specifically want to test if Query B is SLOWER than Query A:
t.test(query_a, query_b, alternative = "less")
The alternative = "less" argument is crucial. This is a "one-tailed test." You're not asking "are they different?" but specifically "is A smaller than B?" Be careful here; switching from a two-tailed to a one-tailed test effectively halves your p-value, which can be a tempting way to "cheat" a result into significance. Don't do that—it's a quick way to lose credibility with your team.
The Trap of the Default Alpha
You'll see 0.05 used as the threshold for "significance" everywhere. It's essentially an industry convention, not a mathematical law. If you're testing something low-risk, like the color of a "Submit" button, 0.05 is fine. But if you're testing whether a new deployment increases memory leaks in a production cluster, you might want a much stricter alpha (like 0.01 or 0.001) because the cost of a False Positive is way higher.
📋 Practical Task
Analyzing Latency Between Two API Gateways
You are comparing the latency of two different API gateways, Gateway_Alpha and Gateway_Beta. Your manager believes that Gateway_Beta is significantly slower than Gateway_Alpha. You have collected 10 latency samples (in milliseconds) for each.
alpha_latency <- c(45, 48, 52, 41, 47, 50, 44, 49, 46, 43)
beta_latency <- c(55, 58, 51, 60, 54, 59, 52, 57, 53, 61)
Your Task:
- Write the R code to perform a t-test to determine if
alpha_latencyis significantly less thanbeta_latency. - Print the result to the console.
- Based on the p-value produced, write a one-sentence conclusion in a comment. Avoid saying "there is an X% chance the null is true"; instead, explain whether the result is statistically significant at the $\alpha = 0.05$ level.
There are no comments for now.