Linear Regression

This is the hands-on post, and its value is in being copy-paste runnable from top to bottom. The strict numbered ordering means each block builds on the last, so a reader can execute them in sequence and watch a complete regression project come together. The goal is muscle memory: by the end they should be able to fit, inspect, and evaluate a model without looking anything up.

The cover sets the expectation — this is code in your editor, not a diagram. Posts 1 through 3 built understanding; this one builds a working artifact.

Step zero is always imports, and bundling them upfront means the rest of the post runs cleanly. The choice of the California housing dataset is deliberate: it's built into scikit-learn (no download friction), it's a genuine regression problem (predicting median house value), and it has eight real features, so the coefficients are interesting to read later.

Grouping the imports also previews the shape of the project: a dataset loader, a train/test splitter, the LinearRegression model, and two metrics (R² and RMSE). A reader who reads only this slide already knows the plan.

Loading and splitting in one step reinforces a discipline established earlier in the series: you never evaluate on the data you trained on. The train_test_split call carves off twenty percent for honest testing, with a fixed random_state so the split is reproducible. Printing the training shape (16512 rows, 8 features) confirms the data loaded correctly and grounds the abstraction in concrete numbers.

This step is short but non-negotiable. Skipping the split is the cardinal sin of model evaluation, and putting it right after loading — before fitting — makes the correct order a habit.

The actual fit is anticlimactically short, which is exactly the point made in post 1: the three-line interface hides a complete least-squares solve. Calling fit() runs the normal equation under the hood (as the comment notes), setting the model's weights and intercept. Printing the intercept confirms the model trained and gives a first concrete number.

The brevity here is pedagogically valuable. After three posts of theory, seeing that all of it collapses into model.fit(X, y) drives home how much the library abstracts — and why understanding the internals from post 3 matters for when things go wrong.

Reading the coefficients is where the model becomes interpretable, delivering on the 'levers' promise from post 2. Pairing model.coef_ with the dataset's feature names and sorting produces a readable ranking of effects. In the California data, median income (MedInc) dominates, which matches intuition — richer areas have pricier homes.

The comment that each coefficient is 'the effect on price per unit of that feature' is the key interpretive sentence. This is the habit that turns a black-box prediction into an explanation a stakeholder can act on. Always attaching names to coefficients is the small discipline that makes this possible.

Inspecting residuals after predicting introduces a diagnostic habit that the 'Common Mistakes' post will lean on heavily. Computing actual minus predicted on the test set, then checking the mean residual, tells you whether the model is systematically biased — a mean near zero means it's not consistently over- or under-predicting. Reporting the worst single miss flags whether any prediction is wildly off.

These two cheap checks catch a surprising number of problems. A nonzero mean residual hints at a missing feature or a systematic bias; a huge worst miss hints at an outlier or a region the model handles badly. Building this inspection into the standard workflow is what separates careful practitioners from those who trust a single accuracy number.

Scoring with both R² and RMSE gives the two numbers practitioners actually report. R² (around 0.58 here) is the share of variance the model explains, useful for comparing models on the same data. RMSE is the typical error in the target's own units, useful for communicating to humans — 'off by about this much on average.'

Computing RMSE as the square root of mean_squared_error is a small but worth-knowing detail (older scikit-learn versions lacked a direct squared=False option in all contexts). Reporting both numbers, rather than just one, is the honest default, and it sets up the next slide's explanation of what they mean.

This explanatory slide makes sure the reader can actually interpret the scores rather than just print them. R² ranges from 1.0 (perfect) down through 0.0 (no better than always guessing the mean) and can even go negative for a model worse than that baseline. RMSE lives in the target's units, so it's the number you quote to non-technical stakeholders.

The guidance to 'use R² to compare models and RMSE to talk to humans' is a practical division of labor. Knowing which metric serves which audience prevents the common mistake of reporting R² to a business owner who has no intuition for what 0.58 means in dollars.

Reproducing the fit from scratch is the post's intellectual payoff: it proves that scikit-learn's fit() is exactly the normal equation from post 3 and nothing more. Adding the bias column, applying w = (XᵀX)⁻¹Xᵀy, predicting on the test set, and seeing the R² match the library's result is deeply convincing. The black box opens and there's just linear algebra inside.

This exercise also reinforces the bias-column trick and gives readers a template they can adapt when they need behavior the library doesn't offer. Once you've rebuilt a model from its math, you trust it — and debug it — at a completely different level.

The pipeline diagram summarizes the whole post as a five-stage flow: load, split, fit, predict, score. Seeing the stages laid out reinforces that every supervised learning project shares this skeleton, regardless of model. The specific code changes, but the shape — get data, hold some back, train, apply, measure — is universal.

This mental template is portable. A reader who internalizes it can structure a project with logistic regression, random forests, or neural networks the same way, swapping only the 'fit' stage. That transferability is part of why starting with the simplest model is so valuable.

The closing tips slide turns the post into a capability checklist: fit in three lines, read coefficient effects, inspect residuals for bias, report R² and RMSE, and reproduce fit() from scratch. It's a self-assessment — if you can do all five, you genuinely understand applied linear regression, not just the API.

Framing it as 'what you can now do' is motivating. The reader sees concrete skills acquired rather than abstract knowledge, which reinforces the value of having worked through the code.

The CTA pivots to failure modes. Now that the reader can build a working regression, the responsible next step is learning how it silently breaks — leakage, unscaled features, misread R². The teaser frames these as quiet, dangerous traps, setting up the 'Common Mistakes' post as essential rather than optional.