Prove
LiveProof-of-Work · Oct–Nov: every verified proof counts. 28 days leftAll outcomes
Skills

Write backpropagation from scratch, with tests

6 weeks · 2 milestones

Your own autodiff, proved correct by tests, then one honest ablation. Research step 1 of the Varsity Curriculum: AI Research. Free resources; your code in a public repo; one person who knows the topic confirms it.

Part of: AI Research · Proves for: Engineers, PG

Milestone map

Milestone map

2 milestones

Build autodiff and prove it with tests

2–4 weeks (about 8 hrs/week, est)

Build a small reverse-mode autodiff in plain NumPy (no deep learning library) that trains a multi-layer network on a real dataset, with unit tests that compare every gradient to a numerical estimate. Keep it in one public repo and commit as you go.

Proof required

Link the public repo: the autodiff code, the test suite and its passing output, and a training curve on a real dataset compared with the same network in PyTorch.

What gets checked

  • Every operation has a gradient test against a finite-difference estimate, and the tests pass.
  • Training on a real dataset matches PyTorch's loss within a stated tolerance.
  • The commit history shows the work built up over time.

Common mistakes

  • One big upload with no commit history.
  • Results that the repo cannot reproduce.

Powstik Guide

A public repo with a small reverse-mode autodiff in plain NumPy (no deep learning library) that trains a multi-layer network on a real dataset, with unit tests that compare every gradient to a numerical estimate.

Steps

  1. Make a public repo.
  2. Write the tests or the evaluation first.
  3. Build the smallest version that passes them.
  4. Write a README: what it is and how to reproduce the results.
  5. Ask someone who knows the topic to check it.

Template

README
Write backpropagation from scratch, with tests
What is here:
How to reproduce:
Results:
Limits:

What gets sent back

  • No tests or evaluation.
  • Code that does not work from the README.
  • Copied code with no history.

Resources

Foundationstart here

What a verifier looks for

  • Every operation has a gradient test against a finite-difference estimate, and the tests pass.
  • Training on a real dataset matches PyTorch's loss within a stated tolerance.
  • The commit history shows the work built up over time.
  • Open the repo: does the code match the results shown?

You'll sign in first, then come straight back here.

Run one ablation and write it up

1–2 weeks (about 6 hrs/week, est)

Write up one ablation on your network (for example the initialisation or the learning-rate schedule) repeated over at least 5 seeds, written up as a two-page report with the plot and what it shows. Put the report in the repo next to the code that produced it.

Proof required

Link the report in your public repo, with the plots and the code or commands that made them.

What gets checked

  • At least 5 seeds per setting, with the spread shown.
  • The report states what was held fixed and what changed.
  • The conclusion claims no more than the plot shows.

Common mistakes

  • Claims the plots do not support.
  • A single seed reported as a result.

Powstik Guide

A short report in the repo with plots and the commands that made them.

Steps

  1. State the question in one line.
  2. Say what you held fixed and what you changed.
  3. Show the plot with the spread over seeds.
  4. Write what it shows, and what it does not.

Template

Report
Question:
Setup (fixed / changed):
Results (plot, seeds):
What it shows:
What it does not show:
Next:

What gets sent back

  • No plot.
  • No statement of what was held fixed.

Resources

Depthgo deeper

What a verifier looks for

  • At least 5 seeds per setting, with the spread shown.
  • The report states what was held fixed and what changed.
  • The conclusion claims no more than the plot shows.
  • Is the conclusion honest about what was not tested?

You'll sign in first, then come straight back here.