Milestone map
Milestone map
2 milestones
Do the problem sets and write them up
7–14 weeks (8–10 hrs/week)
Take Introduction to Numerical Analysis for free and do the problem sets on root finding, interpolation, quadrature, and solving ODEs and linear systems. Write every solution up in LaTeX and keep the source and the PDF in one public repo as you go.
Proof required
Link your public repo with the LaTeX source and the PDF of the problem sets on root finding, interpolation, quadrature, and solving ODEs and linear systems, and show your self-check (Check convergence rates in code).
What gets checked
- Each error bound is proved.
- Measured convergence rates match the proofs (log–log plot).
- Code runs from the README.
Common mistakes
- Copying posted solutions: verifiers read the reasoning and the history.
- A proof that skips the hard step.
- Asking for review before the self-check.
Powstik Guide
A public repo with your LaTeX write-ups of the problem sets on root finding, interpolation, quadrature, and solving ODEs and linear systems.
Steps
- Make a public repo for this course.
- Do one problem set at a time; typeset it in LaTeX and commit.
- Self-check: The course posts no solutions. For every method, prove its error rate, then measure it in code and check that the two agree.
- Fix what the self-check shows, and say what you fixed.
- Ask three people who know the topic to check it.
Template
README Course: Introduction to Numerical Analysis (MIT OpenCourseWare) What is here (problem sets, PDF): Self-check result: The hardest proof and why:
What gets sent back
- Answers with no reasoning.
- Photos of handwriting instead of typeset work.
- Self-check not shown.
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Each error bound is proved.
- Measured convergence rates match the proofs (log–log plot).
- Code runs from the README.
- Pick two proofs and check every step: each argument must be correct and complete, not just present.
- Ask about one step; the answer should be clear.
You'll sign in first, then come straight back here.
Compare two methods with proof and code
1–3 weeks (5–8 hrs/week)
Use what you learned. Make a modelling notebook that compares two methods for one task (Simpson vs Gauss quadrature, or Euler vs Runge–Kutta), proves each one's error rate and confirms both in code. Typeset it in LaTeX (or a notebook with LaTeX maths) in your public repo.
Proof required
Link a modelling notebook that compares two methods for one task (Simpson vs Gauss quadrature, or Euler vs Runge–Kutta), proves each one's error rate and confirms both in code, in your public repo.
What gets checked
- Both error rates are proved.
- The plots confirm the rates.
- The comparison is fair (same cost or same accuracy).
Common mistakes
- A gap in the main argument.
- A result stated but not proved.
Powstik Guide
A modelling notebook that compares two methods for one task (Simpson vs Gauss quadrature, or Euler vs Runge–Kutta), proves each one's error rate and confirms both in code.
Steps
- Write one line: what you will prove or show.
- Draft it, then read it cold the next day.
- Ask someone to read it and mark the first step they doubt.
- Fix it and typeset the final version.
- Ask three people to check it.
Template
Title: What this shows: Main result (statement): Proof: What I would look at next:
What gets sent back
- A main step left unproved.
- Not clearly the person's own work.
- Claims more than it proves.
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Both error rates are proved.
- The plots confirm the rates.
- The comparison is fair (same cost or same accuracy).
- Every argument must be correct and complete; mark the first gap you find.
- Check that the work is the person's own.
You'll sign in first, then come straight back here.