Introduction

If an rpart tree prints only a root node, that does not automatically mean your data has no predictive structure. A positive manual information gain is only one ingredient; rpart still applies stopping rules, minimum node sizes, and pruning logic before it decides whether a split survives in the final tree.

Why a Useful Split Can Still Disappear

Decision-tree learners do not keep every split that reduces impurity. They keep splits that improve the objective enough to justify added complexity.

That distinction matters because developers often do something like this:

1. compute information gain manually
2. see that the value is positive
3. expect the tree to split

rpart is more conservative. A split can have nonzero improvement and still be rejected because:

• the improvement is too small relative to cp
• the node does not satisfy minsplit
• child nodes would violate minbucket
• the split exists in a larger tree but gets pruned away later

So the real question is not "is there any gain at all?" It is "does the split survive the control and pruning rules?"

Check the Split Criterion First

For classification, rpart uses Gini impurity by default, not information gain. If you manually computed entropy-based information gain and expect the tree to mirror that exactly, you may already be comparing different criteria.

To request information splitting explicitly:

1library(rpart)
2
3fit <- rpart(
4  y ~ x1 + x2,
5  data = df,
6  method = "class",
7  parms = list(split = "information")
8)
9
10print(fit)

Without parms = list(split = "information"), your manual entropy calculation and the model's internal criterion may not match.

That mismatch alone explains many "but the data shows information gain" debugging sessions.

The Control Parameters That Commonly Block Splits

The most important settings live in rpart.control.

• 'cp sets the minimum complexity improvement required to keep a split'
• 'minsplit sets the minimum number of observations required before a node may split'
• 'minbucket sets the minimum number of observations allowed in any leaf'
• 'maxdepth caps how deep the tree can grow'

A small example makes this concrete:

1library(rpart)
2
3df <- data.frame(
4  x = c(1, 2, 3, 4, 5, 6),
5  y = factor(c("no", "no", "no", "yes", "yes", "yes"))
6)
7
8fit_default <- rpart(y ~ x, data = df, method = "class")
9print(fit_default)
10
11fit_relaxed <- rpart(
12  y ~ x,
13  data = df,
14  method = "class",
15  control = rpart.control(cp = 0.0, minsplit = 2, minbucket = 1, maxdepth = 5)
16)
17
18print(fit_relaxed)

If the relaxed tree splits but the default tree stays at the root, you have confirmed that the issue is model control, not the total absence of signal.

Root-Only Output Can Also Be Caused by Pruning

Another important point: a tree may split during fitting and still end up printed as a stump after pruning.

Inspect the complexity table:

printcp(fit_relaxed)
plotcp(fit_relaxed)

If you later choose a complexity value that favors the simplest model, pruning can collapse the tree back to a single root node:

1best_cp <- fit_relaxed$cptable[
2  which.min(fit_relaxed$cptable[, "xerror"]),
3  "CP"
4]
5
6pruned <- prune(fit_relaxed, cp = best_cp)
7print(pruned)

This distinction matters. "Never split" and "split, then prune" are different debugging paths.

Inspect the Fitted Object Instead of Guessing

Useful inspection commands include:

fit_relaxed$frame
summary(fit_relaxed)

And for basic data sanity:

table(df$y)
table(df$x, df$y)

With tiny datasets, even a visually obvious pattern may fail the package's regularization rules. Trees are very sensitive to sample size, imbalance, and the exact impurity reduction obtained by a candidate split.

If the predictor has missing values, near-zero variation, or an awkward factor structure, the split you expect may also be weaker than it first appears.

A Practical Debugging Sequence

When rpart returns only a root, debug in this order:

1. verify the actual split criterion
2. relax cp, minsplit, and minbucket
3. inspect printcp
4. compare unpruned and pruned results
5. inspect data size and class distribution

That process usually tells you whether the issue is:

• criterion mismatch
• stopping rules
• pruning
• weak or unstable data

Common Pitfalls

The most common mistake is assuming any positive information gain guarantees a split. rpart still requires the split to clear its complexity and size thresholds.

Another mistake is forgetting that classification trees default to Gini impurity unless you explicitly request information-based splitting.

People also inspect only the final pruned result and conclude the tree never split. Always inspect the complexity table and the less-constrained fit before deciding that.

Finally, tiny toy datasets are especially likely to produce root-only trees under default controls. The defaults are often reasonable, but they are not designed to force a split on every small example.

Summary

• A root-only rpart model does not prove your predictor has zero signal.
• Manual information gain can disagree with the model if rpart is using a different split criterion.
• 'cp, minsplit, minbucket, and maxdepth frequently explain missing splits.'
• Pruning can collapse a previously split tree back to the root.
• Debug by checking the criterion, relaxing controls, and inspecting printcp before blaming the data.