2.8 KiB
CS Thesis Structure (Rough Estimate)
| # | Section | Pages |
|---|---|---|
| — | Abstract | 1 |
| 1 | Introduction — motivation, problem statement, contributions, thesis roadmap | 4–6 |
| 2 | Background / Related Work — prior methods, what you build on, what you differ from | 10–15 |
| 3 | Method — your actual contribution (ROLL loss, KDE formulation, gradient derivation) | 10–15 |
| 4 | Experiments — datasets, baselines, setup, results tables, figures | 12–18 |
| 5 | Discussion — what the results mean, failure modes, limitations | 4–6 |
| 6 | Conclusion — summary, future work | 2–3 |
| — | References | 3–6 |
| — | Appendix (optional) — proofs, extra tables, dataset details | 0–10 |
Total: ~50–80 pages (varies a lot by field norms and advisor preference — ML/systems theses tend toward the lower end)
A few notes for your project specifically:
- Method will be the centerpiece — KDE formulation, the custom autograd backward pass, and how you frame the FPR-constrained objective deserve careful treatment.
- Background should cover: AUC/TPR@FPR optimization literature, KDE-based losses, imbalanced classification baselines (AUROC, focal loss, etc.).
- Experiments you already have a lot of infrastructure for — KEEL datasets + large datasets gives you a good breadth story.
What's your advisor's expected page range, and do you have a target submission date?
Claude> This is very helpful thank you.
- Does page count include figures?
- Does page count include code sections?
- Are all proof in thesises in the appendix and only referenced inside the actual discussion section? Yes, yes, and it depends:
Figures — yes, figures count toward page count. A results-heavy ML thesis can easily have 10+ pages of figures baked into those estimates above.
Code — short snippets (pseudocode, a key algorithm block) go inline in the Method section and count toward pages. Full implementation code goes in the appendix or is omitted entirely — reviewers don't want to read your training loop. Pseudocode is almost always preferred over real code in the main body.
Proofs — no fixed rule, but common practice:
- If the proof is short and central to understanding your contribution (e.g. showing your loss is differentiable), put it inline.
- If it's long or technical but important, put it in the appendix and write "proof in Appendix A" in the main text.
- If it's a known result you're just citing, skip the proof entirely and just cite the paper.
For your thesis specifically: the KDE gradient derivation (the backward pass) is probably worth a compact inline treatment since it is the core technical contribution — but the full derivation details can go in an appendix.