Foundations to FrontierReferences and toolsBezhig

How this book was checked

On this page
  1. Every exercise has a solution
  2. Answers recomputed by script
  3. Code checked by tests
  4. Figures built from exact constructions
  5. Engine notes are quoted, not rewritten
  6. Dated sources
  7. Measurements are observations, not promises
  8. What these checks do not establish

A book that asks you to check your own work should say how its own claims were checked, and what those checks cannot show. This chapter describes the checks behind the solutions, the code, the figures, and the dated facts, and then their limits. Corrections to this edition, when any are needed, are listed on the companion website, bezhig.com/book.

Every exercise has a solution#

Each of the book’s 954 exercises has a complete solution under the same identifier, and the exercise and its solution link to each other. The build that produces the book fails if an exercise has no solution, if two exercises share an identifier, if any cross-reference is undefined or defined twice, or if the number of exercises differs from the count quoted in the preface. These checks establish presence and correspondence. They do not establish that every explanation is correct; the checks below do part of that work.

Answers recomputed by script#

Numerical and symbolic answers were recomputed by scripts instead of being trusted from the page. Each check transcribes a problem’s data and its stated answer, recomputes the answer, exactly wherever possible, with the SymPy computer-algebra library (version 1.14.0), and compares the two. Three scripts cover the core of the book with 422 selected checks, all passing:

  • 333 checks tied to 282 exercises of the calculus modules, the calculus diagnostic, the reviews, and the cumulative assessments;
  • 38 checks of worked solutions in the applied-mathematics units A01–A06, the computation units T03–T05, and project J04;
  • 51 checks tied to 36 exercises of the connecting workshops and the graduate core.

These are selected checks, not one per exercise; each records the actual and expected expressions so that a failure shows exactly where the two disagree.

Several chapters are checked more thoroughly. In calculus Modules 12–14, every number in the numbered pictures, in sections F1 and F2, in problems M12.09–M12.21, M13.09–M13.22, and M14.09–M14.21, and in the spaced reviews, faded examples, and readiness checks is recomputed by a script. The scripts for the frontier chapters F01 and F19 recompute the numbers in their worked examples and solutions from the companion code’s solution files. The scripts for AI01, EL01, and CP01 recompute the numbers in their explanations, worked examples, and solutions, and CP01’s also confirms each claim about which checks a given mistake fails; the GEO01 script recomputes every numerical answer. The AI01 and EL01 scripts compute each value directly from its formula, independently of the code the chapter teaches, and the GEO01 script rebuilds each configuration from the problem’s givens rather than from the solution’s own reasoning, so that a slip in the text and a slip in the code cannot hide each other.

Code checked by tests#

Every lab ships with starter files and tests. The tests are the executable specification: a correct solution passes them, and the starters, which are deliberately incomplete, fail them until you implement the contract.

The companion code’s Python suites for the core of the book passed in full: 96 test methods for the computing, applied-mathematics, and project chapters (the C, A, T, and J chapters), 15 for the connecting workshops, and 43 for the graduate core and its two capstone projects, 154 in all. They ran on Linux x86-64 with Python 3.13.5 and SQLite 3.46.1. A test method that generates many cases counts once. The C++ test programs (ownership, bounded queue, spatial index, and blocked matrix multiplication) passed with GCC 14.2.0 and CMake 3.31.6 in release builds, with their test checks left active, and again in debug builds under the address and undefined-behavior sanitizers. The 39 tests of the F01 and F19 labs pass with Python’s standard library alone.

The labs of the first AI Lab, Engineering Lab, and Algorithms Lane modules were checked one level further: their tests were themselves tested. Each of those labs’ tests was run against deliberately wrong versions of a correct solution, each containing one mistake that learners really make (63 versions for AI01, 86 for EL01, and 50 for CP01), and against correct alternative designs. The tests had to catch the mistakes they exist to catch, and every correct alternative had to pass, so the tests reward a correct solution rather than one particular way of writing it.

Figures built from exact constructions#

The geometry figures are constructed, not drawn by eye. Each one is built from its givens with the TikZ geometry package tkz-euclide, so every point that the givens determine is computed rather than typed in by hand. Each construction also asserts its key lengths and angles as it is built, and a mismatch stops the figure build. Every numerical answer in GEO01 is checked again by the independent coordinate computation described above. Plots of data in the frontier chapters are generated by script from working code, not drawn by hand. The mechanism pictures in many chapters of the core are drawn by one script, which computes each curve, point, and area from its formula. The calculated values their captions quote are asserted in that script and in the tool that places the pictures, and either one stops when a value it computes disagrees. The remaining diagrams are schematics: they show structure, not measurements, and the text says so where the difference matters.

Engine notes are quoted, not rewritten#

The code in each “From the engine” note was copied from its project’s source by a tool, not retyped. The tool records which lines it took and a fingerprint of each excerpt, and it reports any excerpt that no longer matches its source. Every number a note states about its code, such as an error ratio or a table size, was recomputed by a script. The excerpts show the projects as they stood in November 2026, and the code may have changed since. The projects were not built or run for this book: a note shows how an idea is used in real software and is not a test report on that software.

Dated sources#

Every fact that can go out of date (a tool version, an install command, a price, a job posting, a regulation) carries its source and the date it was checked, between September and October 2026. The reference chapters before this one give each source’s scope: a listed page means the cited part was read, not that every page behind the link was. Mathematics does not expire, but these facts do. Check the source again before you rely on one.

Measurements are observations, not promises#

The benchmarks in the text, such as the spatial-index benchmark in J05 and the blocked matrix multiplication in G06, are observations of one machine and one workload. Each is reported with the settings that produced it: the workload, the seed, the repetitions, the timing boundary, and a comparison of outputs against a reference outside the timed region. A result is evidence about that setup, not a promised speedup on other hardware. A fixed random seed makes a run repeatable within the stated software; it does not make sampling assumptions true or guarantee identical floating-point results on every platform.

What these checks do not establish#

  • A script that agrees with a stated answer confirms a computation, not the reasoning around it. Domains, theorem hypotheses, orientations, and model assumptions are argued in the text; they were not machine-checked.
  • Tests check the cases they contain. Passing tests and sanitizer runs are evidence about the paths that were executed, not proof that a program is correct for every input or every thread schedule. ThreadSanitizer, whole-program static analysis, and exhaustive exploration of thread schedules were not run.
  • The core companion code was tested on Linux. The Windows and macOS instructions in its README were not part of those runs, and the optional CUDA source in T02 was never compiled or run on a GPU.
  • No physical hardware (a drone, an embedded board, or a sensor) was built, flown, or measured for these checks. No lab used a production service, real personal data, credentials, a paid service, or a remote deployment. The local network and database labs are educational, not hardened public services, and nothing in this book is validated for safety-critical use.
  • Automated layout checks catch structural problems, such as an undefined reference or a line that runs into the margin. They do not replace reading every page, and errors may remain. If you find one, check the corrections at bezhig.com/book.