Project Walkthroughs: How to Use This Part and One-Time Setup

The book gives you the ideas, the code and the finish lines. This part slows everything down. Each project is cut into small numbered steps, and each step tells you what to do, why, what you should see, and what to do if it breaks. If you can type and run a cell, you can finish every project here.

How to use this part

1. Read one step. 2. Type the code yourself (do not paste). 3. Run only that cell. 4. Compare the output with “You should see”. 5. Only then go to the next step. If your numbers differ a little from the ones shown, that is normal: library versions and random seeds shift results. If they differ by a lot, re-check the previous step. Numbers written with ≈ or “typical” are what you can expect, not a promise.

Where the theory lives

This part is for doing, not for re-teaching. Each project points back to the chapter that explains the ideas, so you can look a concept up without wading through it twice.

Project Book Time Do these Theory and grading live in

day first

1. Telco Customer Day 8 3–4 hours Days 3, 5, 6 Day 8 (p. 173), metrics Day 6 Churn (p. 134), cross-validation Day 5 (p. 114)

2. MNIST: MLP vs Day 12 3–4 hours Days 9–11 Day 12 (p. 235), PyTorch Day CNN 11 (p. 212)

3. Capstone (rebuild Day 14 2–4 hours Everything Day 14 (p. 287), Part IV (p. a model) above 364), rubric (p. 380)

4. GenAI Project Day 15 1 day per Pick one stage Day 15 bridges (p. 301), Part IV Ladder, stages 1–10 stage at a time ladder (p. 367)

How the code is labeled

Every code block carries a small label, so you always know what you are looking at, and a note on how it was checked.

Label Meaning

COMPLETE RUNNABLE Run it as it is (after the steps before it). Nothing is left out. EXAMPLE

STARTER CODE A working beginning. You extend it.

EXERCISE TO COMPLETE Only the skeleton is given. The missing part is yours to write.

REFERENCE One correct version to compare your own against. Write yours IMPLEMENTATION first.

*What “checked” means here Ran on stand-in data: executed end to end on generated data that has the same columns as the real dataset. This proves the code runs and the steps fit together. It says nothing about the real scores. Ran with stand-ins: the logic was executed with a fake embedder and a fake LLM, so the real model and provider were not called. Syntax only / not run here:* needs PyTorch, a download, an API key or a service that was not available when this edition was prepared. Treat these as unverified until you run them, and report anything that differs.

Do this once. Every project below reuses it.

Step 0.1 — Check Python. Open a terminal and run python --version . You need 3.10 or newer. If you see an older version or an error, install the latest Python from python.org.

Step 0.2 — Make a project folder and a virtual environment. A virtual environment is a private copy of Python for this project, so installing packages here cannot break anything else.

COMMANDS

mkdir ml-dl-projects
cd ml-dl-projects
python -m venv env
# Windows:      env\Scripts\activate
# Mac / Linux:  source env/bin/activate
pip install numpy pandas matplotlib scikit-learn jupyter torch torchvision

You should see (env) at the start of your terminal line after activating. If pip is not found, use python -m pip install ... instead. The Project 4 stages need a few more packages; each stage lists its own pip install line.

Step 0.3 — Create this folder layout.

FILE

ml-dl-projects/
├── data/            # downloaded datasets (never commit this)
├── notebooks/       # your .ipynb files
├── outputs/         # plots, saved models
├── README.md
├── requirements.txt
├── .env.example     # variable NAMES only, never real keys (used from Project 4)
└── .gitignore

Step 0.4 — Fill .gitignore so big files and secrets never reach GitHub:

FILE · .gitignore

data/
outputs/*.pt
*.pt
__pycache__/
.ipynb_checkpoints/
env/
.env

Step 0.5 — Start Jupyter. Run jupyter notebook in the project folder, open the notebooks/ folder and create a new Python notebook.

Step 0.6 — First cell of every notebook. It fixes the random seed so your results can be repeated.

COMPLETE RUNNABLE EXAMPLE Checked: ran on stand-in data

import random
import numpy as np

random.seed(42)
np.random.seed(42)

Step 0.7 — Record your versions. When a project works, run pip freeze > requirements.txt . Anyone (including you in six months) can then rebuild the same

pip install -r requirements.txt

Golden habit: after any line that changes data, print .shape and .head() . Half of all beginner bugs show up there immediately.

*The five leakage rules (used in every project below) 1. Split first. Anything that learns from data (a median, a scaler, an encoder, a model) must see training rows only. 2. Put preprocessing inside a Pipeline. Then cross-validation re-learns it on each fold's training part. 3. Choose on validation or cross-validation, never on the test set. Models, settings and thresholds are all choices. 4. Touch the test set once, at the very end, and report whatever it says. 5. Look for leaks you cannot see:* a column that reveals the answer (target leakage) and duplicates or relatives that land on both sides of a split.

Background and worked examples are in Day 5 (p. 114) and Day 8 (p. 173).