Study Methods — how to actually study, not just what

This file is about practice: physical setup, note-taking, and how you know you’ve actually learned a topic rather than just read about it. PLAN.md says what to study; this says how.

Your instinct is right, not myopic: unlike CS, math you only read doesn’t stick. You need friction — pencil, paper, working by hand — because the manipulation itself is where the learning happens, not just the final answer. Below is a concrete system built around that, with an explicit answer to “how do I know I’ve met benchmark.”

1. Physical setup: binder, not notebook

Use an A4 ring binder (or lever-arch), not a bound notebook. A notebook’s fatal flaw for this kind of study is that it’s linear and finite: you’ll want to insert worked corrections, extra derivations, or a redone exercise days after the fact, and a bound notebook won’t let you. A binder does. It also lets you pull a whole topic out to review before writing up notes elsewhere, and re-file it after.

Kit: A4 loose-leaf pad (squared/graph paper, not plain — matrices and diagrams need it), pencil + rubber, ruler, a hole punch, dividers/tabs.

Binder structure — one tab per topic area from PLAN.md, not per-book:

Tab 1: Discrete Math, Logic & Proof
Tab 2: Algorithms & Complexity
Tab 3: Probability & Statistics
Tab 4: Comparative Judgement (Math + Methodology)
Tab 5: Optimisation
Tab 6: Linear Algebra & Calculus
Tab 7: Index & Glossary          ← always at the front, see §4

This mirrors resources.md’s topic split, so “what am I studying” and “where do I file it” are always the same five-or-six buckets — no separate filing taxonomy to maintain.

Page numbering — number by topic block, not globally. e.g. PROB-1, PROB-2, OPT-1. This is the trick that makes a binder actually work over months: you can insert a page anywhere in a block without renumbering everything after it, and you can still cite “see PROB-14” in your index reliably.

One page = one unit of work. Don’t cram multiple exercises onto a page to save paper. You want to be able to pull one page out, redo it, and refile it without disturbing anything else.

2. How to read a math text (not like a novel)

Cover the worked example before reading the solution. Try it yourself first. Stuck after ~10–15 min → reveal only the first line as a hint, then keep going unaided.
Don’t do every exercise. Do enough routine ones to build mechanical fluency, then prioritise proof-oriented and applied ones over repetition of the same mechanical step. If the book has answers to odd-numbered questions, use those for immediate feedback.
Write the definition/theorem out by hand before moving on, even when it’s already printed in front of you. Copying it into your own words in the binder is what makes it retrievable later — this becomes the raw material for §4.

3. Exercise coverage: how you know you’ve hit benchmark on a topic

This is the part that needs an explicit rule, or “am I done with this topic” stays a feeling instead of a decision. Use a simple three-level bar, tracked per topic on one line each in topic_coverage.md, next to this file:

Mechanical fluency — can do the routine, computational exercises correctly without hesitation, without re-deriving the method from scratch each time. Test: pick 3 unseen routine problems from a different chapter/book section on the same technique and solve them cold, no notes. Get all 3 right (allow one arithmetic slip, not a method error) → pass.
Conceptual explanation — can state the definition/theorem correctly from memory and explain why it’s true or what it’s for, not just apply it. Test: close the book, write the statement and a one-paragraph explanation on a fresh page. Compare against the source. If you had to fudge or couldn’t reconstruct it, you’re not there yet — re-read and retry in a day or two, not immediately.
Application — can use the result inside a slightly unfamiliar problem, or connect it to why it matters for the PhD strand it serves (per CLAUDE.md). Test: find or construct one problem that requires combining this topic with something you already know, and solve it. For proposal-critical topics (Bradley- Terry, Pareto analysis, VCD-relevant grammar/complexity work), also write a few sentences connecting the math to the actual strand — this is what turns “I did the exercises” into “I can use this in my research.”

A topic is “at benchmark” when all three pass. Mark it as such in the coverage log with the date. Topics don’t need to be perfect — they need to be at benchmark, or explicitly marked “revisit,” so you always know the true state rather than assuming.

Spaced revisit, not one-and-done: for anything foundational (used repeatedly across the proposal — linear algebra basics, probability, proof technique), redo one cold problem from that topic roughly a month later. If you fail it, that’s not a setback, it’s the system working — put it back in the plan.

4. Note-taking format inside the binder

Use the same lightweight structure every time, so any page is self-orienting without needing surrounding context:

[TOPIC-N]                                        Date: yyyy-mm-dd
Source: <book, chapter/page — from resources.md>

Statement / what I'm working on:
...

Worked attempt (mine, before checking solution):
...

Correction / what I got wrong (if anything):
...

Why this matters for [strand]:                  ← only for proposal-critical topics
...

Index & Glossary (Tab 7): a running list, one line per entry: PROB-14 — Bradley-Terry model, statement + MLE derivation. Keep it updated as you file new pages — this is what makes “find what I wrote about X six weeks ago” a 30-second lookup instead of a binder-wide search. A one-page contents list at the very front of Tab 7, organised by topic block, is enough; don’t over-engineer this into a cross-referenced catalogue.

Digitising: don’t. Keep the binder as the primary record — this is exactly the “structured too heavily and became unmaintainable” failure mode from math_wiki, just moved into a scanner workflow. If a specific derivation genuinely needs to be reusable in typed form (e.g. going into a paper), retype that one thing, not the whole binder.

5. Weekly loop

Pick the next unstarted item in PLAN.md.
Read + work exercises by hand in the binder, using §2.
Run the three-level benchmark test (§3) before checking the box in PLAN.md.
Record the result in topic_coverage.md — tick the levels that passed, set Status, date it. This is the source of truth for “have I learned this,” so update it every time you run the benchmark test, not just when a topic fully passes.
Update the Tab 7 index for any new pages.
Write 2–3 lines in log.md — what you covered, whether it hit benchmark, anything to revisit.

This keeps PLAN.md (what/when), topic_coverage.md (learned/not), log.md (weekly record), and the binder (the actual work) cleanly separated, each with one job.