---

name: practice-problems description: | Practice problems, problem first: extracts problems from a source (a seminar or problem sheet, textbook exercises, lecture slides, a past paper, a handout) and turns each one into an interactive marimo practice item. The reader sees the problem and attempts it first (a marimo-learn widget, a graded form, a Tangle/explorer variant, or a studio page). Hints come next, then the complete explained solution with a green verification cell, the common mistakes and the source page. Assessed questions get a hint and checker only, with the solution date-gated. Use this skill whenever the user asks for practice problems, practice questions, exercises, drills, "problems from chapter N", "make me questions from this sheet/PDF", "quiz me on …", worked problems they can try first, a problem set, extra practice before an exam or seminar, "practice from the lecture slides", "the slide examples as problems", or a practice note per lecture, in any course (MA2403, MA1115, AF2007, FDS, Bloomberg). For MA2403, solutions are worked the Orange-book way (formula page, table, row and column, interpolation) and then checked in code. Builds on marimo-notes (format, build) and model-routing (who reads the source); for whole study guides or mock exams across many notes use study-pack instead.

Practice problems: ask first, then explain fully

The note format, glossary, ⟦links⟧ and build come from marimo-notes. Widget signatures are in skills/marimo-notes/references/teaching-widgets.md §2–§5, and the assessed-work gate is in skills/marimo-notes/references/teaching-patterns.md §Assessed work. This skill adds the problem-first loop and how to get the problems out of a source.

1. Scope and placement (ask only if unclear)

• Source: which file(s) and pages or question numbers. Only course-sanctioned sources (the dropped book is never used).
• Assessed? Is any question from coursework, marked homework or a quiz before its deadline, word-for-word or near it? Check the handbook, Blackboard dates and the course hub's deadlines. Assessed means hint + checker, with the full solution behind --unlock.
• Where it goes:
  • a few problems tied to one note go into that note's Self-Check section;
  • a set goes into a new G<n>_<scope>_practice_problems.py (new_note.py --kind guide), linked from the hub and from each source note's Practice line;
  • lecture-slide examples go into one <lecture-note stem>_practice.py per lecture note, linked from the end of that note and from its hub row (§2b).

2. Extract the problems (cheap models)

• Each source PDF gets one question-banker agent (haiku), all in parallel. The brief gives the path, the page range and the output path in the scratchpad. It returns one row per problem: id | page | verbatim statement (LaTeX) | given data | printed answer (if any) | type | topic | difficulty | assessed flag | figure PNG path.
• Pages with plots, tables or handwriting are rendered to PNG by the agent. Look at the flagged PNGs yourself before trusting the statement.
• A long chapter can go to doc-extractor first, then question-banker on its digest.

2b. From lecture slides (slides mode)

Full recipe in references/slides-mode.md. In short:

1. scripts/extract_slide_examples.py DECKS… --out <scratchpad>/slides (tier 0). It finds the Example / Try it / Try these slides, marks repeats across decks, flags handwriting (ink) and renders PNGs.
2. One question-banker per practice note runs on its candidate ids, copying clean statements from an existing slide-examples guide where one exists.
3. Opus maps the items to lecture notes, writes the item specs (key, hints, solution route, one tabulated variant per item) and reads every ink PNG.
4. notebook-drafter ×N write <lecture stem>_practice.py. Then link each from the end of its lecture note and from its hub row.

3. Design each item (Opus)

Choose the interaction from what the problem asks for:

| Problem asks for | Attempt widget | |---|---| | A number (probability, price, determinant) | NumericEntryWidget(question, correct_answer=<computed>, tolerance) or a .batch().form() with several inputs | | A choice of method, distribution or conclusion | MultipleChoiceWidget. Distractors = the real common mistakes (wrong tail, trials vs failures, forgot to annualise) | | The steps of a proof, test or algorithm | OrderingWidget | | Matching terms, formulas or graphs | MatchingWidget | | "What will this R/Python print?" | PredictThenCheckWidget | | Code (a function, a dplyr pipeline) | stub + # BEGIN/END YOUR CODE + test cell + "Run my tests" (teaching-widgets.md §5) | | A parameter family ("for which k …") | a Tangle sentence or a small explorer, then a numeric check at one value | | A static revision page, no Python | studio view with a "question" and an "answer" state (studio-explainer) |

• Stats (MA2403) solutions take the Orange route (references/orange-book-route.md): name the distribution with its ⟦ob p⟧ page, set up, read the table (page, row, column, entry as printed), interpolate, box the answer, then add one line comparing the table with the exact value. _tools/orange_tables.py reproduces each lookup at table precision, and scipy is only the check.
• Answers are computed in code (scipy, sympy, polars, live R), never typed. A printed answer from the source goes into the checks box comparison, not into the widget.
• Write a variant (new numbers, same method, (own example)) for any problem that is assessed or too easy to memorise.

4. Item layout (problem first)

1. ## P3 — <short title> with the ⟦source page⟧ link line.
2. The problem statement (source wording, LaTeX, the figure if any).
3. The attempt widget in its own cell, named with a prefix (p3_attempt).
4. /// details | Hint 1 (direction) and /// details | Hint 2 (first step). Hints never give the number.
5. A reveal cell with a "Show me the solution" run button (p3_giveup).
6. The solution cell is gated until the reader has answered or given up:

   _answered = (p3_attempt.value.get("value") or {}).get("answered", False)
   mo.stop(not (_answered or p3_giveup.value),
           mo.md("*Attempt the problem (or press “Show me the solution”) to see the worked solution.*"))
   mo.md(rf"""
   /// details | Full solution — P3
       open: True
   **Step 1 — set up.** … *why this step*
   **Step 2 — …** …
   $$\boxed{{…}}$$
   **Common mistakes.** …
   ///
   """)
   

   Numeric and multiple-choice widgets report answered. OrderingWidget reports only {order, correct}, and it sets that while the reader drags, so gate it on correct is True (plus the give-up button). The pp_answered helper in Statistical Distributions and Inference/marimo-notes/W1_L3_discrete_and_normal_practice.py handles all three kinds, and forms too. The solution explains why at each step in the user's voice, ends with the boxed answer, and names the common mistakes and the related note (?file= link + page).
7. A verification cell that is NOT gated, so the build always checks the key. It must not reveal the number before the attempt:

   _ok = abs(P3_KEY - P3_PRINTED) < 5e-4 if P3_PRINTED is not None else True
   mo.callout(mo.md(f"**Answer key check (P3):** matches the source: **{_ok}**"),
              kind="success" if _ok else "danger")
   

   Put P3_KEY (computed) and P3_PRINTED in one hidden key cell near the top of the file. For an Orange-route item the same cell also checks P3_TABLE (the value read the table way with orange_tables) against P3_KEY within the table's tolerance (ob.tol(...)). That proves the book method gives the right answer to the precision printed. A source answer that disagrees is reported in the checks box, and the key is never edited to match.
8. Close with a 📊 quiz summary (add_quiz_summary.py) when there are 3+ public widgets, the checks box and the tags.

Assessed items: steps 1–4 plus a checker form (right/wrong only). Steps 5–6 become the date-gated solution (new_note.py … --unlock <deadline> pattern), and step 7 stays.

Persistence (optional): progress across reloads via moutils StorageItem (libraries-widgets.md §1). It is [R] until it has been tried in one note, so check it renders under marimo run before using it widely.

5. Build and check

.venv/Scripts/python.exe skills/marimo-notes/scripts/build_notes.py "<Course>/marimo-notes/G4_….py" --python .venv/Scripts/python.exe --summary

Then run note-qa. The visual pass must show each problem with no solution visible before an attempt, and the interaction pass must answer one widget and press one give-up button. Script-mode validation leaves widgets unanswered, so solution cells stop silently (expected) and the key-check cells must all be green.

Routing

| Step | Who | |---|---| | Find slide examples, repeats, ink | extract_slide_examples.py (script) | | Extract problems, render figures | question-banker ×N (haiku), parallel; doc-extractor for long chapters | | Assessed? / widget choice / solutions / variants | Opus | | Drafting a large set (≥ 8 items) from Opus's item specs | notebook-drafter (sonnet), then Opus reviews every solution | | Build, visual check | build_notes.py yourself; visual-reviewer (haiku) for the screenshots |

Never

• Show a solution or the numeric answer before the attempt, or before the deadline for assessed work.
• Type an answer key by hand, or change a key to make a check green.
• Use a source the course does not sanction, or quote a whole textbook chapter. Problem statements are for the user's own study notes.