Everything we publish sits under one of these, and every piece is built the same way: state the problem in a sentence, build the intuition, run a small experiment, name where it breaks.
Signal processing is the study of how continuous phenomena — sound pressure, voltage, light, vibration — become sequences of numbers we can compute with, and what we're allowed to do with those numbers without lying about the original. It's the layer beneath almost everything: your phone call, your music, the sensor in an industrial machine, the ECG on a monitor. We write about sampling and the aliasing trap it creates, about the Fourier transform as a change of viewpoint rather than a wall of integrals, about filtering as multiplication in the frequency domain, and about the spectrogram as the honest tool for signals that refuse to sit still. The through-line is intuition first: if you can't picture what a method is doing, the equation won't save you.
Computer vision is the problem of turning a grid of pixel values into a decision — is something there, where is it, which way is it moving, what is it. We cover the building blocks (convolution, edges, gradients), the classical workhorses that still run in production (background models, optical flow, connected components), and the practical reality that no clean dataset warns you about: lighting that shifts, cameras that shake, shadows that get mistaken for objects, and repetitive motion that fools a naive detector. Modern deep networks sit on top of these ideas, not instead of them, and understanding the base makes the fancy layer far less mysterious.
Applied machine learning, as we treat it, is less about the newest architecture and more about the discipline around any model: honest data splits, hunting for leakage, reading the bias–variance tension, and the professional reflex of treating a surprising result as a probable bug before a probable breakthrough. A model that scores brilliantly in your notebook and fails in the world hasn't learned — it's memorised, or it's been handed the answer through a leaky feature. We write about how to catch that early, and why the gap between the lab and reality is the actual job.
Every entry in the register earns its place by following the same route. We start from the one-sentence version a curious non-specialist could repeat at dinner. We build the intuition with the smallest example that still contains the idea. Where we can run code to check a claim, we run it and say so; where we can't, we flag the claim as untested rather than dress it up in confident prose. And we always close on the caveats, because the place a method fails is usually the single most useful thing to know about it. Then we revise — the field moves, and last year's best practice ages fast, so entries carry a review habit rather than a publish-and-forget one.
We keep one local key to remember your cookie choice. Cookie notice.
