# KACTL: 25 pages of competitive programming code held to a page limit > The KTH ICPC team's reference document, kept inside a hard 25 page budget by deleting algorithms that are too common, too rare, or too generic. **kth-competitive-programming/kactl** — KTH Algorithm Competition Template Library (... eller KTHs AC-tillverkande lapp) - Repository: https://github.com/kth-competitive-programming/kactl - Stars: 3,556 · Forks: 1,007 - Language: C++ - License: not declared - Published: 2026-10-07 · Updated: 2026-10-07 · Language: en - Canonical page: https://hysenlabs.com/projects/kth-competitive-programming-kactl ## A document with a page budget, not a library with an API The repository hosts KACTL, described as KTH's ICPC team reference document, consisting of 25 pages of copy-pasteable C++ code for ICPC-style programming competitions. The final browsable version is a PDF, `kactl.pdf`, with the raw source in `content/`. The 25 page figure is not an aspiration, it is the design constraint, and the README states it as a rule: `kactl.pdf` is to be kept to 25 pages plus a cover page. Every design decision follows from that. Algorithms that are very common or simple are excluded, with Dijkstra named as the example, and so are very uncommon ones, with general weighted matching named as the other. What remains is the middle band where a contest problem is plausible and the implementation is not instant to recall. That constraint is also why the repository is shaped around LaTeX rather than a package manager. `content/kactl.tex` is the main file, it imports `chapter.tex` files from subdirectories of `content/`, and each chapter defines source code, text and math as LaTeX. To add or remove code from a chapter you add or remove a corresponding import line, and algorithms that are not in the PDF are simply left commented out in their chapter file. ## What the team deliberately leaves out of the document The README states the selection criteria as aspirations: KACTL algorithms should be useful, short, fast enough, well tested, and where relevant readable and easy to modify. They should not be overly generic, since code is manually typed and generality adds overhead. That last point is the philosophy in one sentence. A general purpose library wins on reuse across many projects. A competition reference sheet wins on being typed accurately in the four minutes before a contest starts, and the two goals conflict. What you get instead of a general implementation is often a specialised one tuned to the shape of contest input. Because so much is commented out by default, the README gives readers a way to see the exclusions directly: run `make showexcluded` to check what is excluded by default, with the note that the default configuration is chosen as a reasonable balance for beginners and advanced teams. Personalised copies are an explicitly supported use, since changing the cover page or choosing a different algorithm set is described as easy. The tree supports that: `Makefile`, `content/`, `doc/`, `stress-tests/`, `old-unit-tests/` and two committed PDFs. ## The MD5 hash that lets you type code from memory The most distinctive feature is a verification trick. Each algorithm has a 6 character MD5 hash printed in the upper right of its entry, and the README advises taking advantage of the hashing when typing in the algorithms, since it lets you confirm you typed the right code. The hash is generated with `hash.sh` or the `:Hash` command from the project's `.vimrc`, and it ignores whitespace and comments. This turns memorisation from an act of faith into a check. You do not need to recall an algorithm exactly; you need to recall it well enough that the hash matches. It also has a practical consequence for typing speed, because you can type from memory and spot an error at the end instead of reading back every line. The coding style described in the README is built for the same reason. It is relatively terse, relying on a handful of macros and typedefs defined in the template file at `content/contest/template.cpp` to shorten the code. Line width is 63 characters with tabs for indentation, where a tab counts as two spaces in the PDF. Every algorithm carries a header with the author, the date it was added, a description, its testing status, and preferably source, license and time complexity. ## Stress tests, compile checks, and a decade of dead unit tests KACTL aims for a high level of confidence in algorithm correctness, and the README describes two mechanisms. Testing is done on online judges and, for newer algorithms, with stress tests that compare output against a more naive algorithm over a large number of randomly generated cases. Those live in `stress-tests/` and run with CI on every commit. The CI does more than run the stress tests. It also verifies that all headers compile, except for an exclude list in `docs/scripts/skip_headers`, and that the LaTeX compiles. That last check is easy to overlook and it is the reason the document cannot silently drift out of sync with the code it claims to contain. There is also `old-unit-tests/`, which the README describes plainly as a couple of broken unit tests last touched about ten years ago. Leaving that directory in place with a note attached is a small honesty that most projects manage less gracefully. The repository shows 3,507 stars and 994 forks, 71 open issues, not archived, with a last push on 2026-08-05 and no tagged releases at all. The absence of releases is consistent with how the project is consumed: you take the PDF, not a version. ## Building it, and the licensing caveat nobody can fix Building the PDF takes one command on a Unix machine, `make kactl`, with `make fast` available as well. The README notes that Windows might work too but is not tested, and points at `doc/README` for more notes. Building is described as something done before important contests rather than on the main branch, which is also when the layout commands for nicer alignment are expected to be inserted. The licensing section is the part to read before copying anything out of the sheet. The README calls the situation a bit unclear, as usual for competitive programming, and says many source files are marked with a license, with a preference for CC0, but many others are not. The stated assumption is that good will is presumed from other authors, and in many cases permission should not be needed since the code is not distributed. That reasoning holds for a document a team prints for itself and does not hold for a commercial product. The repository's licence metadata field carries no value at all, which is consistent with the README's own account, and the `cc0` topic tag reflects the stated preference rather than a uniform licence across every file. Authors and sources are noted in the source files so contributions can be traced back, which is the practical mitigation available. ## Who this suits and who should look elsewhere KACTL is for someone who already knows competitive programming and wants a reliable, terse sheet to work from during a contest. The hard-won part is the curation: an experienced ICPC team has already decided what is worth the scarce page space, and following that selection is most of the value. It is a poor fit as a dependency. There is no package to install, no versioned release, no API contract, and no stability promise, because the artefact is a PDF of code meant to be copied into a file. If you want a maintained C++ container with a version you can pin, this is the wrong shape of project. If you want to understand why a particular algorithm appears in one team's sheet and not another, the exclusion list is genuinely instructive. Compared with the other well known competitive programming references, the distinguishing feature is the page budget. Where other collections grow, KACTL deletes, and the README is explicit that deletion is the mechanism. The MD5 hash is the other thing you will not find elsewhere, and it is the reason many competitors stay with the same sheet for years. ## Conclusion KACTL is not a general purpose algorithm library and does not try to become one. It is a competition sheet with a curator making the hard calls about what belongs: Dijkstra is absent because everyone can type it, general weighted matching is absent because nobody needs it in a four hour contest, and the code is expected to be short and modifiable rather than general. Start with the PDF, then run `make showexcluded` to see what the default configuration leaves out, because the README is clear that a meaningful part of the repository is commented out of the document by default. ## FAQ ### How do I find out which algorithms KACTL leaves out by default? The README tells you to run `make showexcluded`, which lists what the default configuration leaves out. The underlying mechanism is that algorithms not included in the PDF are left commented out in their `chapter.tex` file, and the default is described as a reasonable balance for beginners and advanced teams. ### Why is there no Dijkstra implementation in KACTL? It is excluded on purpose. The README states that due to space issues they also exclude algorithms that are very common or simple, naming Dijkstra as the example, alongside very uncommon ones such as general weighted matching. The 25 page limit for the generated PDF is what forces those omissions. ### What is the 6 character MD5 hash in the corner of each algorithm for? It is there so you can type the algorithm from memory and verify you got it right. The README suggests taking advantage of the hashing when typing in these algorithms, and the hash can be generated with `hash.sh` or the `:Hash` command from the project's `.vimrc`. Whitespace and comments are ignored when computing it. ### Can I use KACTL algorithms in a commercial or closed source project? The README is explicit that the licensing situation is unclear, that many files are marked with a license with a preference for CC0 while many are not, and that good will is presumed from other authors because the code is not distributed. That assumption does not extend to redistribution in a product, so read the header of each specific file before shipping it. ### How is KACTL tested? Testing happens on online judges and, for newer algorithms, with stress tests that compare the output against a more naive implementation across many randomly generated cases, living in the `stress-tests` directory and run with CI on every commit. CI also checks that all headers compile, aside from an exclude list, and that the LaTeX itself compiles. ## Sources - [Issues](https://github.com/kth-competitive-programming/kactl/issues) - [kth-competitive-programming/kactl on GitHub](https://github.com/kth-competitive-programming/kactl) - [README](https://github.com/kth-competitive-programming/kactl/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/kth-competitive-programming-kactl