Page 3 of 8~112 min topic

Decision trees

Build the first working readiness decision tree

Page 3 implements the shortest complete path for the readiness decision tree on hours × practice tests with inspectable intermediate values.

~14 min this pageImplementation

1Learn the idea

Read

Implement the minimal working path

Build only what the claim requires: held-out accuracy is reported and export_text shows the splits used. Prefer boring, deterministic code over frameworks you cannot yet explain. Run the path twice; identical output on this fixture is a feature, not a lack of creativity.

Read

Run the working path

from sklearn.tree import DecisionTreeClassifier, export_text
X=[[1,0],[2,1],[4,1],[5,2],[3,0]]; y=[0,0,1,1,0]
clf=DecisionTreeClassifier(max_depth=2, random_state=0).fit(X[:-1], y[:-1])
print(clf.predict([X[-1]])[0], export_text(clf, feature_names=['hours','practice_tests']))

Expected evidence: holdout prediction plus readable tree. Read each printed intermediate as part of the argument that the path works—not as decoration.

Read

Trace one input end to end

Narrate the journey from raw input to result for a single example from small hours/practice_tests readiness table with one holdout row. If you cannot name an intermediate, the implementation is still too opaque for this lab. Only after this path is solid should you generalize data sources or UI.

Read

Lab notebook: intermediates worth printing

While implementing the readiness decision tree, print or log at least three intermediates that map to the claim (held-out accuracy is reported and export_text shows the splits used). Good intermediates are values a teammate could recompute with a calculator or diff. Bad intermediates are framework traces you cannot explain.

Re-run with small hours/practice_tests readiness table with one holdout row twice. If the second run differs, either the path is nondeterministic (document the seed) or you have hidden global state—both are lab bugs until named.

Read

Worked judgment

Stop adding features once the path supports predict readiness with a path a human can read aloud. Extra UI, extra tools, or extra models belong in later chapters. The mastery bar for this page is simply: a deterministic end-to-end path with intermediates.

Read

Why this stage matters for the readiness decision tree

At the implementation 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 a deterministic path with printed intermediates 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

Go deeper

Before you start

Why this matters

Without running code, predict the final output for fixture small hours/practice_tests readiness table with one holdout row. Name one intermediate value that would prove the prediction. Then answer: what could look successful while actually being wrong at this stage for the readiness decision tree?

Check your understanding

Page assessment

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

1. Can you narrate every intermediate value?
2. Is the fixture deterministic and independently inspectable?
3. Did you avoid framework behavior you cannot explain yet?
4. Does the output still support the decision: predict readiness with a path a human can read aloud?

All responses are required.