TeachingDataScience: LaTeX Course Notes Where the Slides and the Cheat Sheets Share One Source

The gap this fills: teaching material you can actually edit

Most freely available course material arrives as PDFs or slide exports. You can read it, you cannot restructure it. TeachingDataScience takes the opposite position: the deliverable is the .tex source, and the PDF is a build artifact. The README states plainly that "Slides compile to PDF; they aren't checked in pre-built." That single design decision defines both what the repository is good for and what it costs you. The intended audience is instructors who want to cut a two-hour seminar out of a larger course, or self-learners who prefer a printable two-column cheat sheet over a video. The content spans seven named areas in the README's own framing: Machine Learning, Deep Learning, NLP, Generative AI, Maths for ML, and Python, with Graph ML, Reinforcement Learning and career seminars sitting outside the five main courses. It is written for people who already know enough to judge whether a slide is correct, since the README's disclaimer concedes that citations may be incomplete.

Seminar, workshop, course: a three-level composition model

The architecture is a content hierarchy rather than a software one. Raw topic files carry names like maths_linearalgebra_matrices.tex, following a subject_maintopic_subtopic pattern. Above those sit seminars, roughly one hour each. Seminars compose into workshops of four to sixteen hours. Workshops compose into courses of around forty hours. The README describes the relationship directly: each course "is assembled from standalone workshops, which are assembled from standalone seminars." The practical consequence is that the smallest unit is independently usable. You can compile a single seminar without pulling in the course it belongs to, because the driver files are separate. Driver naming follows Main_[Seminar|Workshop|Course]_<Subject>_[Presentation|CheatSheet].tex, so the tier is encoded in the filename. Five course drivers are listed in the catalog table: Main_Course_MachineLearning_Presentation.tex, Main_Course_MathsML_Presentation.tex, Main_Course_Python_Presentation.tex, Main_Course_DeepLearning_Presentation.tex, and Main_Course_GenerativeAI_Presentation.tex. That is the whole assembly mechanism. There is no build script, no Makefile mentioned in the README, and no dependency manifest for the LaTeX side.

One source, two outputs: slides and cheat sheets

The most concrete engineering claim in the README is that every seminar and workshop compiles to both Beamer slides and two-column printable notes "from the same source .tex files." Each unit ships a _Presentation.tex driver and a _CheatSheet.tex driver. This is a real constraint on how the content must be authored: the shared body has to be written so it renders acceptably in both a slide frame and a two-column handout, which usually means avoiding layouts that depend on slide geometry and keeping prose short enough to fit a column. Whether the author achieves that consistently is not something the README demonstrates; the three screenshots under docs/screenshots show a single slide each from the ensemble methods seminar, the LLM embeddings seminar and the Python basics seminar. Those images are described as actual output from the .tex sources, unedited. They are evidence that the pipeline produces slides, not that the cheat sheet variant is well typeset. If the two-column output matters to you, compile one _CheatSheet.tex driver before trusting the claim.

Getting a deck to compile

The README gives exactly one worked command:

cd LaTeX texify -cp Main_Seminar_ML_Intro_Presentation.tex

The stated requirements are a LaTeX distribution, MikTeX or TeX Live, with the instruction to "install packages as prompted." That last phrase is the honest part of the setup story. texify, which ships with MikTeX, resolves missing packages on demand; on TeX Live you would typically reach for latexmk or tlmgr instead, and the README does not cover that path. There is no list of required LaTeX packages, no Docker image, and no CI configuration mentioned, so the first compile on a bare TeX installation is likely to be an iterative loop of missing .sty errors. Budget for that. The Code/ side is better specified: each project has its own environment.yml for conda, and most have a test_*.py suite runnable with pytest. That per-project environment file is a deliberate choice to avoid a single monolithic environment, and it means you activate a different conda environment for each project directory rather than one for the repository.

The Code/ tree is a separate repository in practice

The README organises Code/ into nine categories, from GenAI and agents (langchain, langgraph, llamaindex, crewai, agents, agno, google-adk) through RAG applications (chatbot-faqs, chatbot-multimodal, omni-rag, parsing, graphrag), fine-tuning, document parsing (docling, opendataloader), deep learning (pytorch), classical ML, NLP, GNN, and Indic language work (mahamarathi, sarvam, orgpedia). The README notes the files are "named to match their corresponding .tex file where applicable," which is the only structural link between the prose and the code. Treat the two halves as separate maintenance surfaces. The LaTeX side is stable and slow-moving, since a slide deck that compiles today will probably compile next year. The Code/ side tracks fast-moving libraries: LangGraph, CrewAI, Agno and Google ADK all change their APIs on short cycles, and a notebook pinned in an environment.yml from an earlier date may not run against current releases. Nothing in the README states a versioning or update policy for those environments. If you plan to teach from a Code/ project, pin the environment file and check the notebooks against it yourself rather than assuming currency.

Where it breaks down

The README's own disclaimer is the clearest limitation: "Notes have been built from lots of publicly available material; care has been taken to cite sources, but some may be missing. Point them out and they'll be fixed. Don't depend on this fully; there's always more to improve." For an instructor that is manageable, since you are expected to review material before presenting it. For anyone treating the repository as a reference text, it is a real risk: you cannot tell from the outside which slides are well-sourced and which are not. A second limitation is structural. The References/ directory, which would let you trace claims back to their origin, "exists locally but isn't uploaded, since most of it belongs to others' repos rather than original work." So the citation trail stops at whatever appears on the slide itself. Third, there are no releases. The repository shows no tagged versions, only a last push date, which means there is no snapshot you can pin your course to. If you fork it and the upstream .tex files are reorganised, you have no version boundary to diff against. Finally, this is not a library. There is nothing to import, no API to call, and no runtime behaviour to evaluate. Judging it by software-project criteria, dependency hygiene or test coverage on the LaTeX side, misses what it is.

What it is not: a comparison with the notebook-first approach

The obvious alternative is a notebook-first course such as the fast.ai course materials or the scikit-learn MOOC notebooks, where the primary artifact is an executable .ipynb and the prose lives in markdown cells alongside runnable code. The difference in approach is not cosmetic. In a notebook-first course, the code is the lecture: a student runs a cell and sees a result, and the narrative is bound to that execution. In TeachingDataScience, the code is a satellite. The primary artifact is the .tex file, the output is a PDF, and Code/ holds separate projects that happen to correspond to topics. That makes TeachingDataScience better for lecture delivery and printing, and worse for self-paced learners who want to run something immediately. It also means the repository carries no execution guarantees: a notebook-first course is usually tested in CI so the cells run in order, whereas here the README offers only that most Code/ projects have a pytest suite, with no statement that the notebooks themselves are executed on each change. If your priority is a student who learns by typing, a notebook-first course is the better fit. If your priority is standing in front of a room with slides you can edit, this repository is aimed at you.

Licence, contribution and the cost of keeping it current

The repository is MIT licensed, copyright 2019 Yogesh H Kulkarni. MIT is permissive: you can reuse, modify and redistribute the .tex sources and the code, including in commercial teaching, provided the copyright notice and permission notice are retained. Two caveats follow from the README rather than from the licence text, and neither is legal advice. First, the slides are described as built from third-party public material, and MIT covers the author's contribution, not the rights in whatever was adapted. If you plan to publish a derivative deck, check the individual sources yourself. Second, the References/ directory is not distributed, so you cannot audit provenance from the repository alone. Contribution is handled through CONTRIBUTING.md, which the README says welcomes corrections, new topics, code examples and citation fixes. On maintenance cost: the LaTeX side is cheap to keep alive, since it depends on a TeX distribution that changes slowly. The Code/ side is expensive, because each project's environment.yml pins a stack around libraries like LangChain and LangGraph that break between minor versions. A fork that intends to teach from Code/ needs a per-project update cadence that the upstream repository does not document.

Editorial conclusion

Adopt it if you teach or self-study ML, DL, NLP or GenAI and want editable Beamer sources plus printable notes from one file, and if you are willing to install a LaTeX toolchain and resolve missing packages. Do not adopt it if you need runnable code with pinned, tested dependencies, or if you want a single canonical syllabus: this is a personal teaching archive with a stated disclaimer that some sources may be uncited. Verify two things before committing: that the specific driver file you need compiles in your TeX distribution, and that the Code/ project you plan to run has its own environment.yml with versions you can live with.

Official sources

1. Issues
2. License: MIT
3. README
4. yogeshhk/TeachingDataScience on GitHub