A Pure Function of the Photo

"An answer key that gives a different answer on Thursday was never an answer key. It was an opinion."

Same Photo In, Same Answer Out

The entire solve chain — detect the landmarks, match them to the canonical head, run the bounded solvePnP, build the construction — is designed to be a pure function of two things: the photo and the config. Feed it the same photo and the same calibration and it returns the identical construction, to the last decimal, today and next year. That is not an emergent nicety; it is a hard requirement the whole engine is organized around.

What Determinism Forbids

Purity is a discipline defined by what it refuses to let touch the output. No hidden global state that a previous call could have changed. No dependence on the wall clock or the order files happened to load. No randomness that reaches the result — any sampling must be seeded and fixed, or gone. And crucially, no cache that changes answers: memoization is allowed only when it returns the same value it computed the first time. A cache that ever hands back a different result on a hit isn't an optimization, it's a determinism leak wearing a performance costume.

Why the Grader Needs This

Determinism isn't purity for its own sake — it is the foundation the grader stands on. In Track 6, Loomis compares your drawing against the recovered construction and hands you a score. If that reference construction could drift between sessions, the score would be measuring the engine's mood, not your accuracy. The answer key's authority — the reason a grade means something — rests entirely on the answer being reproducible. Remove determinism and grading collapses into arbitrary numbers.

Determinism Is a Discipline, Not a Gift

Code does not become deterministic by accident; ambient state and hidden randomness creep in unless you actively design them out. You get purity by making every input explicit, keeping functions free of side effects, and testing the property directly: run the analysis twice and demand byte-identical output. The payoff is enormous — a system you can test, reproduce, cache safely, and, above all, trust as a reference. Everything the earlier lessons promised about an answer key cashes out here, in the boring, load-bearing virtue of same-in-same-out.

Code

A pure pipeline, and the test that guards it·python

def analyze(photo, config) -> Construction:
    lm   = detect_landmarks(photo)                  # deterministic given the model
    R, t = solve_pose(lm, CANONICAL_HEAD, config.focal)   # bounded, no randomness
    return build_construction(R, t, config)         # pure geometry, explicit inputs

# The property test: run twice, demand identical results.
a = analyze(photo, config)
b = analyze(photo, config)
assert a == b        # if this EVER fails, hidden state leaked into the output

# A cache is fine ONLY if it returns the SAME answer it computed before:
#   cache[key] = analyze(photo, config)     # memoization, answer-preserving   OK
#   a cache that returns a DIFFERENT result on a hit                           never

Exercise

Take a function you've written that you think is deterministic and audit it for hidden non-determinism: does it read the clock, use randomness without a fixed seed, depend on a mutable global, rely on dict/set iteration order, or touch the filesystem or network? For each one you find, decide whether to make the input explicit, seed it, or remove it. Then add the two-line 'run twice, assert equal' test.

Hint

The usual culprits are time, unseeded randomness, global mutable state, and iteration order over unordered collections. Determinism means every input is on the argument list and nothing ambient reaches the output. The engine earns the right to be an answer key by passing exactly this audit on its whole solve chain.