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?
<shell-maker-end-of-prompt>
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.