Why keep this state instead of recomputing it? The state is small enough to stay local, while recomputing would scan the full input again. The tradeoff is extra update arithmetic per element.
``` Good "Why..." questions name the design choice, compare it with the obvious alternative, and explain the tradeoff. Use code when the paper defines an algorithm, recurrence, kernel, or implementation detail. A short runnable Python demo with an `assert` is useful when it clarifies the idea. Do not force code into prose-only sections. Read `references/method-example.md` when authoring the first method section. ## Results and Comparison Experiments are analysis, not a number dump. State the conclusions first, then use tables and figures as evidence. For results, capture: - **Headline**: workload, baseline, metric, magnitude, and regime. - **Findings**: 2-5 claims, each backed by evidence. - **Tables**: compare regimes, not every number. - **Ablations**: explain which mechanism earned which gain. - **Honest read**: note narrow evaluations, missing tasks, or weak evidence. For comparison, use axes the reader would actually weigh: cost, latency, memory, path length, data needed, or parallelism. State when each method wins and where this paper's method stops winning. ## Figures and Diagrams Use visuals when they teach. Do not add a diagram because a section feels empty. - Paper architecture or method-flow figures belong in Core Method. - Result plots belong in Experiments. - Comparison diagrams belong in Comparison or Related Work. - Mermaid is useful when the reader must track modules, tensors, stages, loop states, branches, or memory movement. Read `references/diagrams.md` for figure curation, Mermaid syntax, and image naming. ## Code References Code refs are implementation handles for claims in the note. Use them when the reader would ask: - Where is this algorithm implemented? - What lines correspond to this formula? - How did they measure this result? - Is there a small runnable version I can inspect? Prefer: 1. Exact author-repo line ranges. 2. High-quality official docs or tutorials. 3. Credible community implementations. 4. Synthesized snippets only when justified. If an official or author-linked repo exists but you still use a synthesized snippet, say why in the ref note. Do not use synthesized code just because it is faster to write. Read `references/code-ref-waterfall.md` before writing `coderefs.json`. ## Q&A Q&A is the reader's self-check. Write 5-8 questions across several angles and difficulty levels. Include a question only if a reader who studied the note would still pause on it. Skip rhetorical recaps like "What is the main idea?" and anything the body already answers. Use these types: - `intuition` (0-1): easy gut-check. "In one line, why does this work?" - `principle` (1-2): design rationale. "Why this choice instead of the obvious alternative?" - `detail` (1-2): mechanical clarity. "What does this symbol, step, or module actually do?" - `limit` (0-1): failure condition. "When does this break?" - `engineering` (1-2): performance envelope. "How does the gain scale, what does it cost, and where does it stop winning?" - `extension` (0-1): transfer. "Where else could this idea apply, and what would need to change?" Answer rules: - Do not fabricate. If the paper does not settle an answer, say what it shows and where the evidence stops. - Show, don't assert. Use a worked example, a few lines of code, napkin math, or paper numbers when that makes the answer click. - Mix difficulty. Readers need a few easy intuition wins, not only deep questions. - For engineering questions, probe scaling and tradeoffs: input size, hardware, memory, latency, accuracy, extra FLOPs, or where another method wins. - Use numbered lists when an answer has multiple reasons, conditions, or steps. Example engineering Q&A: ```text Q: LoRA quality depends on rank r. What sets the right r, and where does increasing r stop paying off? A: The rank sweep shows three forces: 1. Task difficulty: simple classification saturates at low rank; harder generation needs larger r. 2. Subspace coverage: most task updates live in a few dominant directions, so small ranks often match full finetuning. 3. Cost ceiling: higher r raises finetune memory, while merged adapters do not add inference latency. Takeaway: start small, then sweep upward only if validation quality stays below the full-finetune line. ``` ## Final Self-Review Before calling the note done, read the TL;DR, Overview, and first method subsection as a reader. Ask: - Can the reader explain the problem and the fix in five minutes? - Does the contrast with prior methods appear before implementation detail? - Are the strongest numbers tied to the regime where they apply? - Are code refs real and line-specific when a repo exists? - Did any section become a checklist rather than an explanation? Then walk the paper's headings in order. A heading with its own formula, algorithm, module, result, dataset step, training detail, or assumption should not disappear into a background sentence. Update `/tmp/yomitoki/