The one-liner

We’ll use the trial dataset that ships with gtsummary — a small clinical-trial example:

library(gtsummary)

trial |>
  dplyr::select(trt, age, grade, marker, stage) |>
  tbl_summary(by = trt) |>
  add_p()

That’s the whole table. tbl_summary() picks median (IQR) for continuous variables and n (%) for categoricals; add_p() chooses an appropriate test for each row (Wilcoxon, chi-squared, Fisher) and reports the p-value. No manual test selection, no transcription.

Making it publication-ready

A few extra verbs turn it into something you can paste straight into a manuscript:

trial |>
  dplyr::select(trt, age, grade, marker) |>
  tbl_summary(
    by = trt,
    label = list(age ~ "Age (years)", marker ~ "Marker (ng/mL)"),
    statistic = list(all_continuous() ~ "{mean} ({sd})"),
    missing_text = "Missing"
  ) |>
  add_p() |>
  add_overall() |>
  bold_labels() |>
  modify_caption("**Table 1. Baseline characteristics by treatment**")

Here we switched continuous summaries to mean (SD), relabelled variables, added an overall column, and counted missing values explicitly instead of dropping them silently — a small honesty that reviewers notice.

Why it matters

The value isn’t saving five minutes once; it’s that the table is code. Clean a data point, rerun, and every number updates — including the tests and the percentages. There is no window where the manuscript and the data disagree. That’s the whole philosophy behind how we work, applied to the humblest table in the paper.

More clinical recipes live in our Clinical R toolkit. Need this on your own data? Get in touch.

Will you own the code — or just the output?

A results table is a dead end. A script that produces the table is an asset: rerun it on cleaned data, adapt it for the next study, hand it to a colleague. Ask explicitly whether you receive the code, whether it runs end-to-end from raw data, and whether you’re free to reuse it. If the answer is “we’ll send you the figures,” you’re renting, not owning.

Is it reproducible, or a pile of manual steps?

“Reproducible” has a concrete test: can someone else regenerate every number and figure with a single command? A good pipeline makes the cost of a data correction almost zero — rerun and you’re done. A bad one makes it a day of re-clicking. The economics compound over a project’s life:

library(ggplot2)

reruns <- 0:12
manual      <- 45 * reruns          # ~45 min of clicking each time
reproducible <- 90 + 1 * reruns     # one-off setup, then ~1 min per rerun

d <- data.frame(
  reruns = rep(reruns, 2),
  minutes = c(manual, reproducible),
  workflow = rep(c("Manual", "Reproducible"), each = length(reruns))
)

ggplot(d, aes(reruns, minutes, colour = workflow)) +
  geom_line(linewidth = 1.2) +
  scale_colour_manual(values = c(Manual = "#b02a37", Reproducible = "#2f6fed")) +
  labs(
    title = "Why reproducibility pays off after the first correction",
    x = "Number of data updates / reruns", y = "Cumulative minutes spent",
    colour = NULL
  ) +
  theme_minimal(base_family = "sans") +
  theme(legend.position = "bottom",
        plot.title = element_text(face = "bold", colour = "#1b2a4a"))

The reproducible line starts higher — there’s real setup — and then barely moves. Any project touched more than once comes out ahead.

Is the scope in writing?

Vague scope is where consulting relationships go wrong. Before work starts you should have, in writing: the question, the data, the deliverable, the timeline and the price. Fixed-scope milestones beat an open-ended hourly meter for everyone — you know the cost, and the consultant knows what “done” means.

Will there be a handover?

The last hour of a good engagement is a walkthrough: here’s the code, here’s how to rerun it, here’s what to change if your data grows. Without it, you inherit a black box. With it, your team is genuinely more capable than before.

This is exactly how we work — see our services or the FAQ for the details, then get in touch.

What Cohen’s d is

Cohen’s d is the difference between two group means expressed in pooled standard deviation units — so it’s comparable across studies and scales. Rough conventions:

• d ≈ 0.2 — small
• d ≈ 0.5 — medium
• d ≈ 0.8 — large

Compute it in R

Base R doesn’t have a built-in, but it’s a three-line function. We’ll use the sleep dataset (extra hours of sleep under two drugs):

cohen_d <- function(a, b) {
  n1 <- length(a); n2 <- length(b)
  s_pooled <- sqrt(((n1 - 1) * var(a) + (n2 - 1) * var(b)) / (n1 + n2 - 2))
  (mean(a) - mean(b)) / s_pooled
}

g1 <- sleep$extra[sleep$group == 1]
g2 <- sleep$extra[sleep$group == 2]

cohen_d(g2, g1)

[1] 0.8321811

A d of this size points to a substantial difference between the two drugs — regardless of whether the p-value happens to clear 0.05 at this sample size.

p-value vs effect size

t.test(g2, g1, paired = TRUE)$p.value  # significance

[1] 0.00283289

cohen_d(g2, g1)                        # magnitude

[1] 0.8321811

These answer different questions. Report both: significance says “unlikely to be noise,” effect size says “and here’s how much it matters.” A tiny d with a tiny p-value (from a huge sample) is statistically significant but often practically irrelevant.

Reporting

State the effect size with a confidence interval, and interpret it in the units your audience cares about — a “medium” d means little to a clinician until you translate it back into real outcomes.

Want effects reported and interpreted properly, not just p-values? That’s how we work.

From a 2×2 table to the metrics

Start with the counts of test result against true disease status:

tp <- 90; fp <- 10    # test positive: disease present / absent
fn <- 20; tn <- 180   # test negative: disease present / absent

metrics <- function(tp, fp, fn, tn) {
  sens <- tp / (tp + fn)
  spec <- tn / (tn + fp)
  c(
    Sensitivity = sens,
    Specificity = spec,
    PPV = tp / (tp + fp),
    NPV = tn / (tn + fn),
    `LR+` = sens / (1 - spec),
    `LR-` = (1 - sens) / spec
  )
}

round(metrics(tp, fp, fn, tn), 3)

Sensitivity Specificity         PPV         NPV         LR+         LR- 
      0.818       0.947       0.900       0.900      15.545       0.192 

Sensitivity and specificity are properties of the test itself. PPV and NPV — the questions patients actually care about (“I tested positive, do I have it?”) — are not: they shift with prevalence. Likelihood ratios neatly combine sensitivity and specificity and feed directly into Bayesian updating of pre-test odds.

Watch prevalence move the predictive values

Hold sensitivity and specificity fixed and sweep prevalence from rare to common:

library(ggplot2)

sens <- 0.90; spec <- 0.95
prev <- seq(0.001, 0.5, length.out = 300)
ppv <- (sens * prev) / (sens * prev + (1 - spec) * (1 - prev))
npv <- (spec * (1 - prev)) / (spec * (1 - prev) + (1 - sens) * prev)

d <- data.frame(
  prevalence = rep(prev, 2),
  value = c(ppv, npv),
  metric = rep(c("PPV", "NPV"), each = length(prev))
)

ggplot(d, aes(prevalence, value, colour = metric)) +
  geom_line(linewidth = 1.2) +
  scale_colour_manual(values = c(PPV = "#2f6fed", NPV = "#17a2b8")) +
  scale_y_continuous(labels = scales::percent, limits = c(0, 1)) +
  scale_x_continuous(labels = scales::percent) +
  labs(
    title = "Predictive values depend on prevalence (sens = 90%, spec = 95%)",
    x = "Disease prevalence", y = "Predictive value", colour = NULL
  ) +
  theme_minimal(base_family = "sans") +
  theme(legend.position = "bottom",
        plot.title = element_text(face = "bold", colour = "#1b2a4a"))

At 1% prevalence a “positive” from this excellent test is more likely to be a false alarm than a true case — the PPV is low even though sensitivity and specificity are high. Move to a specialist clinic where a third of patients truly have the disease and the same test’s PPV soars.

The takeaway

Quote sensitivity and specificity to describe the test; quote PPV and NPV with the prevalence they assume, or you’ll mislead. Better still, present predictive values across the plausible prevalence range — exactly what the diagnostic-test calculator in our live demos does interactively.

Part of our Clinical R toolkit. Evaluating a test on your own data? Let’s talk.

Fit the model

We’ll predict fuel economy (mpg) from weight and horsepower using the built-in mtcars:

fit <- lm(mpg ~ wt + hp, data = mtcars)
summary(fit)

Call:
lm(formula = mpg ~ wt + hp, data = mtcars)

Residuals:
   Min     1Q Median     3Q    Max 
-3.941 -1.600 -0.182  1.050  5.854 

Coefficients:
            Estimate Std. Error t value Pr(>|t|)    
(Intercept) 37.22727    1.59879  23.285  < 2e-16 ***
wt          -3.87783    0.63273  -6.129 1.12e-06 ***
hp          -0.03177    0.00903  -3.519  0.00145 ** 
---
Signif. codes:  0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1

Residual standard error: 2.593 on 29 degrees of freedom
Multiple R-squared:  0.8268,    Adjusted R-squared:  0.8148 
F-statistic: 69.21 on 2 and 29 DF,  p-value: 9.109e-12

Reading the summary

• Coefficients (Estimate) — the change in mpg for a one-unit increase in that predictor, holding the others constant. Here each 1,000 lb of weight (wt) costs several mpg.
• Pr(>|t|) — the p-value for “this coefficient is zero.” Small means the predictor carries information beyond the others.
• Multiple R-squared — the share of variance in mpg explained by the model. Adjusted R-squared penalises extra predictors and is the fairer figure to compare models.
• Residual standard error — the typical size of the model’s prediction errors, in mpg.

A tidy table

broom turns the model into data frames that are easy to report or plot:

library(broom)
tidy(fit, conf.int = TRUE)   # coefficients + 95% CIs

# A tibble: 3 × 7
  term        estimate std.error statistic  p.value conf.low conf.high
  <chr>          <dbl>     <dbl>     <dbl>    <dbl>    <dbl>     <dbl>
1 (Intercept)  37.2      1.60        23.3  2.57e-20  34.0      40.5   
2 wt           -3.88     0.633       -6.13 1.12e- 6  -5.17     -2.58  
3 hp           -0.0318   0.00903     -3.52 1.45e- 3  -0.0502   -0.0133

glance(fit)                  # model-level stats

# A tibble: 1 × 12
  r.squared adj.r.squared sigma statistic  p.value    df logLik   AIC   BIC
      <dbl>         <dbl> <dbl>     <dbl>    <dbl> <dbl>  <dbl> <dbl> <dbl>
1     0.827         0.815  2.59      69.2 9.11e-12     2  -74.3  157.  163.
# ℹ 3 more variables: deviance <dbl>, df.residual <int>, nobs <int>

library(ggplot2)
ggplot(mtcars, aes(wt, mpg)) +
  geom_point(colour = "#17a2b8") +
  geom_smooth(method = "lm", se = TRUE, colour = "#2f6fed", fill = "#2f6fed22") +
  labs(title = "mpg vs weight, with linear fit", x = "Weight (1000 lb)", y = "mpg") +
  theme_minimal(base_family = "sans") +
  theme(plot.title = element_text(face = "bold", colour = "#1b2a4a"))

Don’t skip the diagnostics

A regression is only trustworthy if its assumptions hold. Run plot(fit) to check linearity, constant variance and normal residuals before you interpret a single coefficient.

Regression with confounders, interactions or a report to produce? That’s our statistical analysis service.

Where Python is the better call

Be fair first. If the deliverable is a production ML service, a deep-learning model, or code that has to live inside a larger Python application, use Python. The tooling, the deployment story and the surrounding ecosystem are simply built for that. Choosing R there would be stubbornness.

Where R pulls ahead

For classical statistics, R is the reference implementation, not a port. Methods appear on CRAN as researchers publish them; mixed-effects models (lme4), survival analysis (survival) and a thousand niche tests are first-class, battle-tested and consistent. And two things matter enormously for consulting deliverables:

• ggplot2 for figures a journal will accept without a fight.
• Quarto / R Markdown for reports that regenerate from data with one command.

A quick illustration — a full model summary and diagnostics are one line away, with output designed to be read, not parsed:

fit <- lm(mpg ~ wt + hp, data = mtcars)
summary(fit)$coefficients

               Estimate Std. Error   t value     Pr(>|t|)
(Intercept) 37.22727012 1.59878754 23.284689 2.565459e-20
wt          -3.87783074 0.63273349 -6.128695 1.119647e-06
hp          -0.03177295 0.00902971 -3.518712 1.451229e-03

That coefficient table, the assumption checks, and a publication figure all come from the same object, in the same session, in a language whose defaults were chosen by statisticians.

The real answer: match the tool to the deliverable

The tribal “R vs Python” framing is mostly noise. The useful question is what has to exist at the end:

• A peer-reviewed results section, APA tables or clinical figures → R.
• A reproducible report that reruns monthly → R (or Quarto with either).
• A model embedded in a product or a deep-learning pipeline → Python.
• A team already fluent in one → usually that one, unless the deliverable demands otherwise.

We pick R for our niche because it makes the statistical, reproducible, publication-ready deliverable the path of least resistance. Different niche, different answer — and a consultant who tells you otherwise is selling, not advising.

Curious whether R fits your project? Tell us what you’re trying to produce and we’ll give you a straight answer — even if it’s “use Python.”

Fit the model

Using the trial dataset (response = tumour response), we adjust for age, marker level and disease stage. Fit on complete cases so the model and the ROC use the same rows:

library(gtsummary)

d <- na.omit(trial[, c("response", "age", "marker", "stage")])
fit <- glm(response ~ age + marker + stage, data = d, family = binomial)

Odds ratios that read cleanly

tbl_regression(exponentiate = TRUE) turns the raw log-odds coefficients into odds ratios with confidence intervals and p-values — the format a journal expects:

tbl_regression(fit, exponentiate = TRUE) |>
  bold_p() |>
  modify_caption("**Adjusted odds ratios for tumour response**")

An odds ratio above 1 raises the odds of response, below 1 lowers them; the confidence interval tells you how sure you can be. Because these are adjusted, each is the effect of that variable holding the others fixed.

How well does it discriminate?

Significant predictors don’t guarantee a useful model. The ROC curve plots sensitivity against 1 − specificity across every threshold, and the area under it (AUC) summarises discrimination in a single number — 0.5 is a coin flip, 1.0 is perfect:

library(pROC)

roc_obj <- roc(d$response, fitted(fit), quiet = TRUE)

plot(roc_obj, col = "#2f6fed", lwd = 3, legacy.axes = TRUE,
     xlab = "1 - Specificity", ylab = "Sensitivity",
     main = "ROC curve")
abline(0, 1, lty = 2, col = "#8a93a6")
text(0.6, 0.2, sprintf("AUC = %.3f", as.numeric(auc(roc_obj))),
     col = "#1b2a4a", font = 2, cex = 1.3)

Report the AUC with a confidence interval (ci.auc(roc_obj)) and, if the model will guide decisions, calibration too — discrimination and calibration answer different questions.

The takeaway

Odds ratios tell you which factors matter and by how much; the AUC tells you whether the model is worth using at all. A complete logistic analysis reports both — and, ideally, is reproducible from raw data to figure in one script.

See this alongside survival and diagnostic-test recipes in our Clinical R toolkit.

Build the contingency table

We’ll use the built-in HairEyeColor data, collapsed to a hair-colour × eye-colour table:

tab <- apply(HairEyeColor, c(1, 2), sum)
tab

       Eye
Hair    Brown Blue Hazel Green
  Black    68   20    15     5
  Brown   119   84    54    29
  Red      26   17    14    14
  Blond     7   94    10    16

Run the test

chisq.test(tab)

    Pearson's Chi-squared test

data:  tab
X-squared = 138.29, df = 9, p-value < 2.2e-16

A small p-value means hair colour and eye colour are not independent — there’s an association. The test compares the observed counts to the counts you’d expect if the two variables were unrelated.

mosaicplot(tab, color = c("#1b2a4a", "#2f6fed", "#17a2b8", "#5aa0ff"),
           main = "Hair vs eye colour", las = 1)

The mosaic plot makes the association visible — tile areas are proportional to counts, and the pattern departs clearly from a plain grid.

When to use Fisher’s exact test instead

The chi-square approximation gets unreliable when expected cell counts are small (a common rule: any expected count < 5). R even warns you. In that case, use the exact alternative:

fisher.test(matrix(c(8, 2, 1, 9), nrow = 2))

    Fisher's Exact Test for Count Data

data:  matrix(c(8, 2, 1, 9), nrow = 2)
p-value = 0.005477
alternative hypothesis: true odds ratio is not equal to 1
95 percent confidence interval:
    2.057999 1740.081669
sample estimates:
odds ratio 
  27.32632 

Check expected counts with chisq.test(tab)$expected, and switch to fisher.test() for small tables.

Reporting it

Report the statistic, degrees of freedom, p-value and — crucially — an effect size such as Cramér’s V, since a large sample can make a trivial association “significant.”

Categorical data with more structure than a single table? That’s where we come in.

The setup

Two groups, equal means (so the null hypothesis is true), but one group is twice as variable and half as large. Any test with a nominal α of .05 should reject in about 5% of runs.

set.seed(2026)

sim_once <- function() {
  a <- rnorm(60, mean = 50, sd = 5)    # larger, tighter group
  b <- rnorm(30, mean = 50, sd = 10)   # smaller, noisier group
  c(
    student = t.test(a, b, var.equal = TRUE)$p.value,
    welch   = t.test(a, b, var.equal = FALSE)$p.value
  )
}

res <- t(replicate(10000, sim_once()))
colMeans(res < 0.05)

student   welch 
 0.1088  0.0507 

The Student’s t-test rejects a true null far more often than the promised 5%, while Welch stays honest.

Seeing it

library(ggplot2)

rates <- data.frame(
  test = c("Student's t", "Welch's t"),
  rate = colMeans(res < 0.05)
)

ggplot(rates, aes(test, rate, fill = test)) +
  geom_col(width = 0.55, show.legend = FALSE) +
  geom_hline(yintercept = 0.05, linetype = "dashed", colour = "#1b2a4a") +
  scale_fill_manual(values = c("#2f6fed", "#17a2b8")) +
  scale_y_continuous(labels = scales::percent_format(accuracy = 0.1)) +
  labs(
    title = "Empirical Type I error under unequal variances and group sizes",
    subtitle = "10,000 simulated studies; dashed line marks the nominal 5% level",
    x = NULL, y = "False positive rate"
  ) +
  theme_minimal() +
  theme(plot.title = element_text(face = "bold", colour = "#1b2a4a"))

The takeaway

When variances and group sizes are both unequal, the classic pooled-variance t-test can be badly miscalibrated — here it roughly doubles the false-positive rate. Welch’s test handles this case and behaves almost identically when variances are equal. That asymmetry is why t.test() in R uses Welch by default, and why we do too.

Fit the model

We’ll use the trial dataset (ttdeath = time, death = event) and adjust for treatment, age and grade:

library(survival)
library(gtsummary)

cx <- coxph(Surv(ttdeath, death) ~ trt + age + grade, data = trial)

tbl_regression(cx, exponentiate = TRUE) |>
  bold_p() |>
  modify_caption("**Hazard ratios for death**")

A hazard ratio above 1 means a higher instantaneous risk; below 1, lower. exponentiate = TRUE converts the model’s log-hazard coefficients into the hazard ratios you actually report.

Now check proportional hazards

This is the step that separates a defensible analysis from a fragile one. cox.zph() tests whether each effect is stable over time:

zph <- cox.zph(cx)
zph

       chisq df    p
trt    2.053  1 0.15
age    0.163  1 0.69
grade  4.365  2 0.11
GLOBAL 6.666  4 0.15

Large p-values (and a non-significant GLOBAL row) mean the proportional-hazards assumption is reasonable. Back it up visually — the scaled Schoenfeld residuals should scatter flat around zero, with no trend:

par(mfrow = c(1, 3), mar = c(4, 4, 2, 1), family = "sans")
plot(zph, col = "#2f6fed", lwd = 2)

When the assumption fails

A significant test isn’t the end of the world — it’s a signpost. The usual responses: stratify on the offending variable, fit a time-varying coefficient, split follow-up into time intervals, or switch to an accelerated failure-time model. What you should never do is report the hazard ratio as if the assumption held when it didn’t.

The takeaway

Fitting the Cox model is one line; earning the right to interpret it is the second line, cox.zph(). Report both, and your reviewers have one fewer thing to worry about.

Pair this with Kaplan–Meier curves and the rest of the Clinical R toolkit.

Step 1: the ANOVA

We’ll use the built-in PlantGrowth data — plant yields under a control and two treatments:

fit <- aov(weight ~ group, data = PlantGrowth)
summary(fit)

            Df Sum Sq Mean Sq F value Pr(>F)  
group        2  3.766  1.8832   4.846 0.0159 *
Residuals   27 10.492  0.3886                 
---
Signif. codes:  0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1

A small p-value for group says the groups are not all equal — but not which pair drives it.

Step 2: Tukey’s HSD

Never just run a bunch of t-tests here. Tukey’s Honest Significant Difference compares every pair while controlling the family-wise error rate:

TukeyHSD(fit)

  Tukey multiple comparisons of means
    95% family-wise confidence level

Fit: aov(formula = weight ~ group, data = PlantGrowth)

$group
            diff        lwr       upr     p adj
trt1-ctrl -0.371 -1.0622161 0.3202161 0.3908711
trt2-ctrl  0.494 -0.1972161 1.1852161 0.1979960
trt2-trt1  0.865  0.1737839 1.5562161 0.0120064

Each row is a pairwise difference with an adjusted confidence interval and p-value. Any interval that excludes zero is a significant difference.

par(mar = c(4, 8, 3, 1), family = "sans")
plot(TukeyHSD(fit), col = "#2f6fed")

Intervals crossing the dashed zero line are not significant; those entirely to one side are.

Before you trust it

ANOVA assumes roughly normal residuals and similar variances across groups. Check the residuals (plot(fit)) and normality; if variances differ badly, use oneway.test() (Welch) instead, and if normality fails, the Kruskal–Wallis test.

Running group comparisons in your data? We’ll handle the assumptions and the write-up.

The one-liner

Suppose we plan a two-group trial and consider a standardized difference of d = 0.5 (a “medium” effect) clinically meaningful. How many participants per group for 80% power at α = .05?

power.t.test(delta = 0.5, sd = 1, sig.level = 0.05, power = 0.80)

     Two-sample t test power calculation 

              n = 63.76576
          delta = 0.5
             sd = 1
      sig.level = 0.05
          power = 0.8
    alternative = two.sided

NOTE: n is number in *each* group

About 64 per group. The same function inverts in any direction — fix n and it returns the power, fix power and n and it returns the smallest detectable effect.

The more honest answer: a power curve

A single number hides how sensitive the design is to your effect-size guess. A curve makes the trade-off visible:

library(ggplot2)

grid <- expand.grid(
  n = seq(10, 150, by = 2),
  d = c(0.3, 0.5, 0.8)
)
grid$power <- mapply(
  function(n, d) power.t.test(n = n, delta = d)$power,
  grid$n, grid$d
)

ggplot(grid, aes(n, power, colour = factor(d))) +
  geom_line(linewidth = 1.1) +
  geom_hline(yintercept = 0.80, linetype = "dashed", colour = "#1b2a4a") +
  scale_colour_manual(
    values = c("#17a2b8", "#2f6fed", "#1b2a4a"),
    labels = c("d = 0.3 (small)", "d = 0.5 (medium)", "d = 0.8 (large)")
  ) +
  scale_y_continuous(labels = scales::percent) +
  labs(
    title = "Power curves for a two-group t-test",
    subtitle = "Dashed line marks the conventional 80% target",
    x = "Participants per group", y = "Statistical power", colour = NULL
  ) +
  theme_minimal() +
  theme(legend.position = "bottom",
        plot.title = element_text(face = "bold", colour = "#1b2a4a"))

The curve tells the real story: if the true effect is small (d = 0.3), even 150 per group leaves you underpowered — and if the budget only allows 30 per group, you are implicitly betting on a large effect.

Beyond the t-test

Base R also ships power.prop.test() for two proportions and power.anova.test() for one-way ANOVA. For more complex designs — mixed models, survival endpoints, cluster randomization — the honest tool is simulation: generate data under your assumed model a few thousand times and count how often the analysis detects the effect. That is a topic for a future post.

Planning a study and unsure about the numbers? We do this for a living.

Two tools, used together

• Shapiro–Wilk test (shapiro.test) — a formal test of the null “the data are normal.”
• Q–Q plot (qqnorm + qqline) — a visual check: normal data hug the diagonal line.

Use both, and trust the plot when they seem to disagree.

set.seed(5)
x <- rnorm(80, mean = 10, sd = 2)

shapiro.test(x)

    Shapiro-Wilk normality test

data:  x
W = 0.98151, p-value = 0.3009

par(mfrow = c(1, 2), mar = c(4, 4, 2, 1), family = "sans")
hist(x, col = "#2f6fed33", border = "#1b2a4a", main = "Histogram", xlab = "x")
qqnorm(x, col = "#17a2b8", pch = 19, main = "Normal Q-Q plot")
qqline(x, col = "#b02a37", lwd = 2)

Points close to the red line and a bell-shaped histogram: normality is a reasonable assumption here.

The big caveat: sample size

The Shapiro–Wilk test is sensitive to sample size. In small samples it can miss real non-normality; in very large samples it flags trivial, harmless departures as “significant.” So:

• Large n: a significant Shapiro–Wilk often doesn’t matter — the test you’re running is robust, and the Q–Q plot looks fine. Don’t panic over the p-value.
• Small n: the test has little power, so lean on the Q–Q plot and subject-matter knowledge.

If it’s not normal

You have good options: a nonparametric test (Mann–Whitney, Kruskal–Wallis), a transformation (log, square-root), or a method that doesn’t need normality of the raw data. For regression, remember it’s the residuals that should be normal, not the predictors.

Assumption checks are where analyses quietly go wrong. We make them explicit.

A realistic load series

We’ll simulate two years of daily consumption with an annual heating/cooling cycle, a weekday-vs-weekend pattern, a gentle upward trend and random noise — the ingredients of real metering data:

library(ggplot2)

set.seed(42)
n   <- 730
day <- seq(as.Date("2024-01-01"), by = "day", length.out = n)
t   <- seq_len(n)
wday <- as.integer(format(day, "%u"))          # 1 = Mon … 7 = Sun

annual  <- 20 * cos(2 * pi * t / 365)           # seasonal heating/cooling
weekend <- ifelse(wday >= 6, -18, 4)            # weekends draw less
trend   <- 0.015 * t                            # slow growth
load    <- 130 + annual + weekend + trend + rnorm(n, 0, 5)

d <- data.frame(day, load)

ggplot(d, aes(day, load)) +
  geom_line(colour = "#2f6fed", linewidth = 0.4) +
  labs(title = "Simulated daily electricity load",
       x = NULL, y = "Load (MWh)") +
  theme_minimal(base_family = "sans") +
  theme(plot.title = element_text(face = "bold", colour = "#1b2a4a"))

Decompose it: trend + season + remainder

stl() (seasonal-trend decomposition using loess) splits the series into interpretable components. With a weekly period it isolates the Monday-to-Sunday cycle and leaves the annual swing in the trend:

ts_load <- ts(load, frequency = 7)
fit <- stl(ts_load, s.window = "periodic")

plot(fit, col = "#1b2a4a", main = "STL decomposition of daily load")

Each panel is a story: the trend shows underlying growth and the seasonal swing, the seasonal panel is the repeating weekly shape, and the remainder is what’s left — where anomalies and one-off events show up.

Read the weekday profile

Aggregate straight from the data to get the average load by day of week — the “load profile” utilities plan around:

labs_wday <- c("Mon", "Tue", "Wed", "Thu", "Fri", "Sat", "Sun")
prof <- aggregate(load ~ wday, data = data.frame(load, wday), FUN = mean)
prof$label <- factor(labs_wday[prof$wday], levels = labs_wday)

ggplot(prof, aes(label, load)) +
  geom_col(fill = "#17a2b8", width = 0.7) +
  labs(title = "Average load by day of week",
       x = NULL, y = "Mean load (MWh)") +
  theme_minimal(base_family = "sans") +
  theme(plot.title = element_text(face = "bold", colour = "#1b2a4a"))

The weekend drop is unmistakable — and once it’s quantified, it feeds directly into forecasting and capacity planning.

Where this goes next

Decomposition is the foundation; from here the same data supports forecasting (forecast, prophet, or a seasonal ARIMA), anomaly detection on the remainder, and interactive dashboards that let operations teams explore load themselves. That last step is squarely our Shiny practice, and the energy sector is one of the industries we serve.

Have meter or market data that needs turning into decisions? Tell us about it.

The rule

• Two groups → two-sample t-test.
• Three or more groups → one-way ANOVA.

They agree for two groups

For exactly two groups, ANOVA’s F equals the t statistic squared — same p-value, same conclusion:

set.seed(10)
g <- factor(rep(c("A", "B"), each = 30))
y <- c(rnorm(30, 0), rnorm(30, 0.6))

t_res <- t.test(y ~ g, var.equal = TRUE)
a_res <- summary(aov(y ~ g))

c(t_squared = unname(t_res$statistic^2),
  F_value   = a_res[[1]][["F value"]][1])

t_squared   F_value 
 12.58062  12.58062 

The two numbers match — a t-test is just ANOVA with two groups.

Why not many t-tests?

With three groups you might be tempted to run A-vs-B, A-vs-C, B-vs-C. Don’t: each test carries a 5% false-positive risk, so three tests push your overall error rate well above 5%. ANOVA asks “is there any difference?” in a single test at the right error rate.

library(ggplot2)
ggplot(PlantGrowth, aes(group, weight, fill = group)) +
  geom_boxplot(alpha = 0.7, show.legend = FALSE) +
  scale_fill_manual(values = c("#2f6fed", "#17a2b8", "#5aa0ff")) +
  labs(title = "One-way ANOVA compares 3+ groups at once",
       x = NULL, y = "Weight") +
  theme_minimal(base_family = "sans") +
  theme(plot.title = element_text(face = "bold", colour = "#1b2a4a"))

After a significant ANOVA

ANOVA tells you a difference exists, not which. Follow up with a post-hoc test that controls for multiple comparisons — see one-way ANOVA with post-hoc tests in R.

Comparing groups in your own data? We’ll pick the right test and defend it.

Declare the parameters

In the report’s YAML header:

---
title: "Monthly Quality Report — `r params$site`"
format: docx
params:
  site: "Site A"
  month: "2026-06"
---

Inside the document, params$site and params$month drive the filtering:

monthly <- readr::read_csv("data/measurements.csv") |>
  dplyr::filter(site == params$site,
                format(date, "%Y-%m") == params$month)

Render the batch

One small driver script produces the whole set:

sites <- c("Site A", "Site B", "Site C")

for (s in sites) {
  quarto::quarto_render(
    "monthly_report.qmd",
    execute_params = list(site = s, month = "2026-06"),
    output_file = paste0("report_", gsub(" ", "_", s), "_2026-06.docx")
  )
}

Fifty sites is the same loop with a longer vector.

Why this beats copy-paste

library(ggplot2)

d <- data.frame(
  n_reports = rep(1:50, 2),
  approach  = rep(c("Manual copy-paste", "Parameterised Quarto"), each = 50)
)
d$hours <- ifelse(d$approach == "Manual copy-paste",
                  d$n_reports * 1.5,          # ~1.5 h per hand-edited report
                  6 + d$n_reports * 0.02)     # one-time template + render time

ggplot(d, aes(n_reports, hours, colour = approach)) +
  geom_line(linewidth = 1.2) +
  scale_colour_manual(values = c("#1b2a4a", "#17a2b8")) +
  labs(
    title = "Cumulative effort: hand-edited vs. parameterised reports",
    subtitle = "Illustrative estimates — the template costs more up front, then almost nothing",
    x = "Number of reports", y = "Hours of analyst time", colour = NULL
  ) +
  theme_minimal() +
  theme(legend.position = "bottom",
        plot.title = element_text(face = "bold", colour = "#1b2a4a"))

Beyond the hours, the real win is consistency: every report is generated from the same logic, so a fix or improvement lands in all fifty at the next render — and none of them can silently drift out of sync with the data.

The difference in one sentence

• Pearson measures the strength of a linear relationship, using the raw values.
• Spearman measures the strength of a monotonic relationship, using the ranks — so it captures “as X goes up, Y goes up” even when the shape is curved, and it shrugs off outliers.

Where they disagree

Take a strong but curved (exponential) relationship:

library(ggplot2)
set.seed(3)
x <- 1:60
y <- exp(x / 18) + rnorm(60, 0, 2)

pear <- cor(x, y)                      # Pearson
spear <- cor(x, y, method = "spearman") # Spearman

ggplot(data.frame(x, y), aes(x, y)) +
  geom_point(colour = "#17a2b8", alpha = 0.7) +
  labs(title = sprintf("Pearson r = %.2f   vs   Spearman rho = %.2f", pear, spear),
       x = "X", y = "Y") +
  theme_minimal(base_family = "sans") +
  theme(plot.title = element_text(face = "bold", colour = "#1b2a4a"))

The relationship is essentially perfect and increasing, so Spearman is near 1. Pearson is lower because the relationship isn’t a straight line — it’s penalised for the curvature.

Getting the test

cor.test(x, y, method = "spearman")

    Spearman's rank correlation rho

data:  x and y
S = 2214, p-value < 2.2e-16
alternative hypothesis: true rho is not equal to 0
sample estimates:
      rho 
0.9384829 

cor.test() gives the coefficient, the test statistic and a p-value for either method.

How to choose

• Pearson when the relationship looks linear and the data are roughly normal without wild outliers.
• Spearman when the relationship is monotonic but curved, the data are ordinal, or outliers/skew are present.

Always plot first — a coefficient without a scatter plot hides curvature and outliers. And whichever you use: correlation is not causation.

Correlation is usually the opening question. For regression, confounder adjustment and a write-up, that’s our work.

What 95% actually means

A 95% CI is built by a procedure that, across many repeated samples, produces intervals capturing the true value 95% of the time. It is not a 95% probability that the truth lies in this particular interval — once computed, the interval either contains the true value or it doesn’t.

Watch it work

Draw 100 samples from a population with a known mean of 50, build a 95% CI from each, and colour the ones that miss:

library(ggplot2)
set.seed(7)
sims <- t(replicate(100, {
  x <- rnorm(30, mean = 50, sd = 10)
  as.numeric(t.test(x)$conf.int)
}))
d <- data.frame(study = 1:100, lo = sims[,1], hi = sims[,2])
d$miss <- d$lo > 50 | d$hi < 50

ggplot(d, aes(study, ymin = lo, ymax = hi, colour = miss)) +
  geom_linerange(linewidth = 0.8) +
  geom_hline(yintercept = 50, linetype = 2, colour = "#1b2a4a") +
  scale_colour_manual(values = c("FALSE" = "#2f6fed", "TRUE" = "#b02a37"),
                      guide = "none") +
  labs(title = paste0("Of 100 intervals, ", sum(d$miss), " missed the true mean"),
       x = "Sample number", y = "Estimated mean") +
  theme_minimal(base_family = "sans") +
  theme(plot.title = element_text(face = "bold", colour = "#1b2a4a"))

Close to 5 in 100 miss — that’s the 95% procedure behaving exactly as designed.

Computing them

x <- rnorm(30, 50, 10)
t.test(x)$conf.int          # mean, t-based

[1] 45.57248 54.44697
attr(,"conf.level")
[1] 0.95

prop.test(40, 50)$conf.int  # proportion (Wilson-style)

[1] 0.6585632 0.8949784
attr(,"conf.level")
[1] 0.95

For proportions, prefer the Wilson interval over the textbook Wald formula — it behaves far better for small samples and extreme proportions.

Why report them

A CI answers “how big, and how sure?” in one line — far more useful than a bare p-value. Wide interval, more uncertainty; narrow, more precision.

Intervals are only as good as their assumptions. Checking those is our job.

The definition

The p-value is the probability of observing data at least as extreme as yours, assuming the null hypothesis is true.

Small p → your data would be surprising if there were no effect → evidence against the null. That’s it. It is not the probability that the null is true, and it says nothing about how big or important an effect is.

The simulation that makes it click

If the null hypothesis is true, p-values are uniformly distributed between 0 and 1. Let’s see it — run 5,000 t-tests on data with no real difference:

library(ggplot2)
set.seed(1)
pvals <- replicate(5000, t.test(rnorm(25), rnorm(25))$p.value)

ggplot(data.frame(pvals), aes(pvals)) +
  geom_histogram(breaks = seq(0, 1, 0.05), fill = "#2f6fed",
                 colour = "white", alpha = 0.85) +
  geom_hline(yintercept = 5000/20, linetype = 2, colour = "#b02a37") +
  labs(title = "Under the null, p-values are uniform",
       subtitle = "5,000 t-tests on groups with no true difference",
       x = "p-value", y = "Count") +
  theme_minimal(base_family = "sans") +
  theme(plot.title = element_text(face = "bold", colour = "#1b2a4a"))

The bars are flat — every p-value is equally likely. And notice the leftmost bar: about 5% of tests give p < 0.05 even though nothing is going on. That 5% is your false-positive rate, and it’s exactly why running many tests and keeping the “significant” ones is so dangerous.

Three traps to avoid

• p is not effect size. With a big enough sample, a trivial difference becomes “significant.” Always report an effect size and a confidence interval.
• Non-significant ≠ no effect. It may just mean too little power.
• p-hacking is real. Deciding tests after seeing the data inflates false positives — pre-specify.

A p-value is one line in a larger story. Want the whole analysis done right? We can help.

A complete theme in one function

library(ggplot2)

theme_rverse <- function(base_size = 12) {
  theme_minimal(base_size = base_size) +
    theme(
      plot.title = element_text(face = "bold", colour = "#1b2a4a",
                                size = rel(1.15)),
      plot.subtitle = element_text(colour = "#5a6478",
                                   margin = margin(b = 10)),
      plot.title.position = "plot",
      axis.title = element_text(colour = "#1b2a4a"),
      panel.grid.minor = element_blank(),
      panel.grid.major = element_line(colour = "#e4e8f0"),
      legend.position = "bottom",
      strip.text = element_text(face = "bold", colour = "#1b2a4a")
    )
}

scale_colour_rverse <- function(...) {
  scale_colour_manual(values = c("#2f6fed", "#17a2b8", "#1b2a4a",
                                 "#e8590c", "#6f42c1"), ...)
}

Before and after

The same plot, the same code — the only difference is the final line.

p <- ggplot(iris, aes(Sepal.Length, Petal.Length, colour = Species)) +
  geom_point(alpha = 0.75) +
  labs(title = "Default ggplot2 look",
       subtitle = "Grey panel, default palette, top-left legend nowhere in particular",
       x = "Sepal length (cm)", y = "Petal length (cm)")
p

p +
  labs(title = "With theme_rverse() and the brand palette",
       subtitle = "One added line — typography, grid and colours now match every other figure") +
  theme_rverse() +
  scale_colour_rverse()

Make it the default

The step most teams skip: you don’t have to add + theme_rverse() to every plot. Set it once at the top of the script or in a package .onLoad():

theme_set(theme_rverse())
options(ggplot2.discrete.colour = scale_colour_rverse)

From that line on, every ggplot in the session is on-brand by default — and when the brand changes, you update one function, re-render, and every figure in every report follows.

Where to keep it

• One project? A R/theme.R file sourced at the top of the analysis.
• A team? An internal R package (yourorg.theme) — install once, library() everywhere. This is exactly the kind of small internal package we build in our package development service.