46 lines
2.8 KiB
Markdown
46 lines
2.8 KiB
Markdown
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.
|
||
|