Grokking AI Algorithms is twelve chapter folders, and one requirements file installs PyTorch for all of them

Twelve chapter directories, and the setup names one file in one of them

The top level is the book's table of contents as directories: `ch01-intuition_of_ai` through `ch12-generative_image_models`, covering search fundamentals, intelligent search, evolutionary algorithms and advanced approaches, swarm intelligence split into ants and particles, machine learning, neural networks, reinforcement learning, large language models and generative image models. There is also `readme_assets/`, a `tests/` directory, a `requirements.txt` and an `__init__.py` at the repository root.

The setup procedure walks through four steps and then gives exactly one runnable example:

cd ch03-intelligent_search/informed_search
python3 maze_astar.py

That path also reveals the depth: a chapter directory contains subdirectories of its own, and nothing in the README enumerates them. The other eleven chapters have to be found by browsing the tree, and the file inside each one is named per example rather than listed anywhere.

There is a second route to the same material, and it is not in this repository. The README points at a Colab notebook whose path names Grokking-Artificial-Intelligence-Algorithms-Notebook, a separate project with its own history. Choosing the notebook means a browser and a Google runtime instead of a local interpreter.

`python`, `python3` and bare `pip` are mixed across four setup steps

The first step is the sensible one: install Python, then confirm that `python` and `pip` point at the same interpreter with `python -m pip --version`. The reason to check is that a mismatched pair installs packages into a different environment than the one that runs your code.

What follows does not hold that line. The virtual environment step uses `python3 -m venv .venv` and `source .venv/bin/activate` on macOS and Linux, and a separate pair for Windows PowerShell. The install step then drops the interpreter prefix entirely:

pip install --upgrade pip
pip install -r requirements.txt

That is the exact case step one warns about. A bare `pip` can resolve to a different interpreter than the `python3` whose virtual environment was just activated, and the two commands above will not complain if it does. Adding the prefix costs nothing.

The run command is `python3` again, on every platform, which also means the Windows instructions are only half translated: the environment step there uses `py -3` and `\.venv\Scripts\Activate.ps1`, and the run step still says `python3`.

One requirements file for twelve chapters, so a maze script pulls in PyTorch

There is a single `requirements.txt` at the top level, and the documented install applies it wholesale. That file carries a deep learning entry:

torch>=2.3

under a comment that says it is required for chapters 9, 11 and 12. Anyone following the setup to run the A* maze in chapter 3 installs PyTorch anyway, and the README acknowledges the size problem by telling Apple Silicon users to take the `arm64` build or follow the upstream instructions if CUDA is needed. The install command has no chapter filter and the file has no extras, so the size is unavoidable through the documented path.

The version policy inside the file is uneven. numpy is the only dependency with a ceiling, `numpy>=1.26,<3`, which is a sensible guard for a compiled scientific stack. Everything else is a floor: scipy, pandas, matplotlib, seaborn, scikit-learn, joblib and torch all have no upper bound, so the combination you get depends on the day you install.

The file also mixes concerns. Four entries, flake8 with mccabe, pycodestyle and pyflakes, sit under a comment about optional linting, and the last three are flake8's own dependencies, so following the install gives you four packages no chapter imports, one of them twice over.

A tests/ directory sits in the tree with no runner in the dependency list

The repository has a `tests/` directory and no way to run it from the documented setup. The four setup steps end at running one example script, no test command appears anywhere in the README, and the requirements file lists no test runner at all. It lists four linting packages instead.

So the state of the tree is a test suite that a fresh clone cannot execute, and lint tooling that no documented command invokes either. The absence is consistent: there is no `.github` directory in the top level, which means nothing in the tree runs those tests on commit or on a pull request. For a book repository that is a normal amount of ceremony, but it also means the code has no automated check that a reader can point to.

The root `__init__.py` is the other loose end. It makes the repository root importable as a package, which helps the chapter modules import each other during a local run, but with no `setup.py` and no `pyproject.toml` in the tree there is nothing to install it into. The dependencies are installed; the code is meant to be run from inside a chapter directory, which is exactly what the one documented command does.

Chapter 10 is reinforcement learning, and nothing says whether it needs torch

The requirements comment places `torch` in chapters 9, 11 and 12, and the README's requirements list offers a PyTorch-compatible GPU for the heavy demos in chapters 11 and 12. Chapter 10 is reinforcement learning, and the file says nothing about it. A reader who wants to run the reinforcement learning chapter has three possibilities and no guidance: the chapter may need torch and fall outside the comment, it may deliberately use a lighter library, or it may be the one chapter written to run without a framework. The repository does not say which.

The directory naming is inconsistent in the same small way. `ch01-intuition_of_ai` and `ch08-machine_learning` use underscores inside the slug, `ch06-swarm_intelligence-ants` and `ch07-swarm_intelligence-particles` use a hyphen, and the swarm pair is further split into two directories where most chapters are one. Scripts that walk the tree, or a reader scripting a path, has to handle three conventions.

The README is also candid about when not to use the code. It says the examples will make more sense if you have read the book, that the repository should not be consulted as the book is read page by page, and that its purpose is to be a practical reference when you are implementing an algorithm or want the technical view. That is a sensible framing, and it is the opposite of what a reader who found the repository first usually wants.

AGPL-3.0 on teaching code, with the README saying nothing about reuse

The licence is AGPL-3.0, recorded in a `LICENSE.txt` at the top level. That is a copyleft licence, and it is a departure from the permissive terms most readers of example code assume they have. The code here is deliberately meant to be read, adapted and pasted into a working program, which is the use case a copyleft licence constrains most directly.

Nothing in the repository softens it. The README does not discuss reuse, does not offer a permissive alternative for the snippets, and does not distinguish the chapter implementations from anything else in the tree. There is one licence file and it applies to the whole repository.

That is a licensing fact rather than legal advice, and it is the kind of thing worth settling before an afternoon of work rather than after, because the question a team actually has is whether a chapter's implementation can live inside a product it ships. Reading `LICENSE.txt` settles it. Guessing from the fact that the book is a Manning title does not.

Where a browser notebook or the library's own implementation fits instead

Two alternatives are already in view. The first is the Colab notebook in the separate `-Notebook` repository, which runs the same material in a browser with nothing to install, at the cost of a hosted runtime and no local files. For someone evaluating the algorithms that is the faster route by a wide margin. For someone who needs the code on disk, in a repository, next to their own work, it is not a substitute.

The second is the library itself. The requirements file already includes scikit-learn, matplotlib and torch, so anything the chapters demonstrate with those is available as a maintained implementation with its own release cycle. The difference in approach is the point of the book: a chapter shows the algorithm in full, including the parts a library hides, and these files are written to be read rather than depended on. They have no package metadata, no CI in the tree, and lower-bound pins only.

So the practical split is by intent. Use this repository to understand an algorithm closely enough to reimplement it. Use the library when you need the behaviour. Use the notebook when you need neither a local environment nor a dependency you have to reason about.

Editorial conclusion

Use this repository to read a specific algorithm the way the book teaches it, chapter by chapter, and to have runnable code beside the prose. Do not use it as a library: there is no packaging metadata, no CI in the tree, and lower-bound-only pins on every dependency except numpy. Before running anything, create the virtual environment and check that your interpreter and pip agree with `python -m pip --version`, because the documented commands mix `python`, `python3` and bare `pip`, and read LICENSE.txt before adapting a chapter's implementation into a product, since the repository is AGPL-3.0.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. Project website
4. README
5. rishal-hurbans/Grokking-Artificial-Intelligence-Algorithms on GitHub