Page 4 of 8~112 min topic

Decision trees

Measure whether the readiness decision tree works

Page 4 turns “it ran” into executable checks for the readiness decision tree on hours × practice tests.

~14 min this pageEvaluation

1Learn the idea

Read

Make the metric executable

Translate the claim into assertions or a tiny eval harness. The metric to protect is: held-out accuracy plus a tree text dump that mentions both features. Always record the denominator (how many cases) beside any rate. A percentage without a denominator is marketing, not measurement.

Read

Run the checks

from sklearn.tree import DecisionTreeClassifier
X=[[1,0],[2,1],[4,1],[5,2]]; y=[0,0,1,1]
clf=DecisionTreeClassifier(max_depth=2, random_state=0).fit(X[:3], y[:3])
acc=(clf.predict(X[3:])==y[3:]).mean(); print({'holdout_acc':float(acc)})

Expected evidence: holdout_acc value. A passing assertion proves only the behavior it names; broader usefulness still needs the chapter’s full limits.

Read

Say what the metric does not prove

Be explicit: beating the baseline (majority-class accuracy on the holdout before fitting the tree) on this fixture does not prove behavior under overfit tree with max_depth unrestricted on tiny data, or missing feature names in export. Label observations separately from conclusions so the next page inherits honest evidence about the readiness decision tree.

Read

Lab notebook: denominator discipline

Compute held-out accuracy plus a tree text dump that mentions both features with the denominator written beside the rate every time. For this chapter, the evaluation set is intentionally tiny; that is allowed only if you say so in the evidence. Compare against majority-class accuracy on the holdout before fitting the tree before celebrating.

Add one negative case aimed at overfit tree with max_depth unrestricted on tiny data, or missing feature names in export. A suite with only happy cases cannot protect the readiness decision tree when the characteristic failure appears in review.

Read

Worked judgment

If a check is expensive or flaky, shrink it until it is deterministic on small hours/practice_tests readiness table with one holdout row. Flaky green builds teach the team to ignore gates. Record what this page does not prove so security-ops and mastery-ship inherit honest limits.

Read

Why this stage matters for the readiness decision tree

At the evaluation stage for decision-trees, the job is narrower than finishing a product demo. You are creating one progressive evidence piece about small hours/practice_tests readiness table with one holdout row that later pages inherit without redefining success. Keep that fixture small enough to inspect by hand, keep outputs copy-pasteable as text, and refuse to narrate this baseline as if it were a production SLA: majority-class accuracy on the holdout before fitting the tree.

For this page specifically, success looks like metrics with explicit denominators and a negative case while still centering the user decision to predict readiness with a path a human can read aloud. If you cannot point to a file, command, or assertion that proves that for the readiness decision tree, stay on this page instead of advancing.

Decision tree glossary

Previous · Next

Read

Extra mastery block

For decision-trees, write a transfer example that differs in one constraint from the chapter scenario. Keep the quality bar fixed. Explain which check still applies.

Go deeper

Before you start

Why this matters

Write one independent check that would catch a fake pass for this lab. Prefer a check tied to held-out accuracy plus a tree text dump that mentions both features over a check that only asserts “no exception.”

Check your understanding

Page assessment

Answer from memory. Completion is saved from this evidence, not from opening the next page.

1. Is the metric computed with an explicit denominator?
2. Does a failing gold case actually fail the harness?
3. Did you separate observations from conclusions?
4. What remains unproved after these checks?

All responses are required.