Grokking Machine Learning: the code that ships with the book, chapter by chapter

Ten chapter directories and one environment file

The repository is structured as a companion to a book, and the structure is the whole design. The description says it is the repository for the book Grokking Machine Learning, published by Manning, and the primary language recorded for the project is Jupyter Notebook, which tells you what the code actually is. At the top level sit ten chapter directories named after their subjects: Chapter_03_Linear_Regression, Chapter_04_Testing_Overfitting_Underfitting, Chapter_05_Perceptron_Algorithm, Chapter_06_Logistic_Regression, Chapter_08_Naive_Bayes, Chapter_09_Decision_Trees, Chapter_10_Neural_Networks, Chapter_11_Support_Vector_Machines, Chapter_12_Ensemble_Methods and Chapter_13_End_to_end_example. The numbering skips 02 and 07, and the README explains why: chapter 2 is about types of machine learning and chapter 7 is about accuracy, neither of which has a code link beside it. A single requirements.txt at the root covers the environment for all of them.

The progression is deliberately slow

What makes the chapter list worth reading as a curriculum is the order. It opens with what machine learning is, then the types of it, and then a chapter on drawing a line close to the points, which is linear regression. From there it moves to underfitting, overfitting, testing and regularization, which is where the ideas that separate a working model from a broken one are introduced. The perceptron algorithm follows, then logistic classifiers as the continuous version of the same idea, then a chapter on how classification models are measured, then the Naive Bayes model, decision trees, neural networks, support vector machines and the kernel method, and finally ensemble learning. The last chapter is described as putting it all in practice, with a real life example of data engineering and machine learning. That ordering is the argument the repository makes by its structure: each model is introduced after the measurement tools that let you judge it, not before.

The requirements file pins a 2019 scientific Python stack

Here is the practical catch, and it is worth reading the file rather than assuming pip will sort it out. The requirements list is a complete environment freeze rather than a minimal set of libraries, and it reads like a conda export from around 2019. It includes the Anaconda toolchain itself, with conda 4.8.3, conda-build, conda-package-handling and conda-verify among the entries, alongside anaconda-client, anaconda-navigator and anaconda-project. The notebook stack is there too, with jupyter 1.0.0, jupyterlab 1.2.6, jupyter-client, jupyter-console and jupyter-core, ipython 7.12.0, ipykernel, ipywidgets, ipython-genutils, and both jedi and parso-era tools. The data and plotting libraries sit alongside, with h5py, bokeh 1.4.0, graphviz, dask 2.11.0 and distributed, and there is an entry for coremltools 3.3, the toolchain for converting models to Apple's Core ML format. Installing this file as it stands on a modern machine is the first hurdle, and it is a real one rather than a formality.

The dependency list is wider than the chapters need

It is worth separating the dependencies you need from the ones the export happened to capture, because installing a frozen conda environment wholesale is a slow way to discover what the chapters actually require. The heavy hitters visible in the list are dask 2.11.0 and distributed 2.11.0, which appear as a pair, along with joblib 0.14.1 and the whole IPython stack. The testing and linting tools are also present, with hypothesis 5.5.4 for property based testing, flake8, isort, autopep8 and astroid, plus pytest-era tooling. Whether you need dask at all depends on the chapter you are working in, and the honest approach is to install a modern scientific Python environment with the plotting and numerical libraries you need and then run the notebooks, rather than reproducing a 2019 environment wholesale. The book is a teaching text, so the code is written to be read, and read code often needs less than the environment that produced it.

A discount code and a book link, which is what this repository is

It is worth being clear about what this repository is and is not, because the directory names look like a library and they are not. The README describes it as the repository for the book and links to the Manning page for the book itself, along with a cover image and a discount code for the book. There is no package, no importable module name, no setup file and no release history, and the repository has no GitHub releases, so there is no version to install with pip. The code exists to be read next to a chapter, and the repository's job is to make that possible by keeping the notebooks in a directory named after the chapter they belong to. If you are looking for the ideas, the book is the source; if you want to run the examples as written, this is where they are; if you want a maintained library for linear regression or gradient boosting in production, this is the wrong place to look.

No licence means you have to ask

The licence field on the repository is empty, meaning the project has no licence that GitHub could classify, and there is no LICENSE file in the tree. That is a real constraint rather than a formality, and it deserves a paragraph rather than a footnote. Without a licence grant, the default position under copyright law is that you do not have permission to copy, modify or redistribute the notebooks, and the fact that the code is visible on a public repository does not change that. The book itself is a commercial product sold by a publisher, and the notebooks are the supporting files for it, so a reading of the arrangement that assumes permissiveness is an assumption rather than an entitlement. If you intend to run the code internally for learning, that is a different question from republishing it, and if you intend to publish something derived from a chapter, ask the publisher first. The absence of a licence file also means there is no notice to carry forward, and no warranty, so the code carries whatever risk a notebook written for a book happens to carry.

Running the notebooks means fixing the environment first

There is no install command in the README, so the practical path is the standard one for a notebook repository: create a Python environment, install the packages the chapter needs, and start a notebook server from the chapter directory. The only file that tells you what those packages are is requirements.txt, and as noted it is a full environment freeze from an older era. In practice the sequence is to work out which handful of libraries a given chapter directory needs, install current versions of those, and open the notebooks one at a time. Chapter 13, the end to end example, is the one most likely to need the full stack, since it covers data engineering as well as the model, so it is the one to tackle with a working environment rather than a partially guessed one. If a notebook fails on an import, the fix is almost always a version mismatch rather than a mistake in the teaching, and the pinning in the file is the record of what worked at the time it was written.

What the repository is genuinely good for

Judged as an engineering artefact rather than a package, this repository has a specific strength. The chapter directories make it possible to see how a book's arguments map onto code, and the mapping is unusually visible because each directory holds everything for one idea. The end to end chapter, with data engineering in the same place as the model, is the one that most resembles a real project, and the ensemble and support vector machine chapters are the ones to look at if you want to compare two model families side by side. What it does not offer is reuse, currency or a guarantee. The code is frozen at the time of publication, the environment it describes has aged, the dependency list contains packages that have been superseded, and there is no licence to grant you the right to build on it. Read it as a well-structured curriculum with runnable examples, decide separately whether you want to run it, use it or publish anything derived from it, and do not expect the environment to install cleanly as written.

Editorial conclusion

Grokking Machine Learning suits a reader who wants to run the code alongside the text, or an instructor who wants the chapter structure of a book that moves from linear regression to ensembles, and it suits a learner who values a progression that starts with a line drawn through points. It does not suit a team looking for a maintained machine learning library or a reproducible environment to build on, because the pinned requirements describe a Python stack from around 2019 and the repository has no licence that GitHub could classify. Before running anything, read the requirements file and expect to install or upgrade the scientific stack yourself, and read the LICENSE question on the repository page before you reuse a chapter's code in something you publish.

Frequently asked questions

Official sources

1. Issues
2. luisguiserrano/manning on GitHub
3. README