Pattern Recognition with Mathematics and Programming

In the previous post, we established that biological hardware (human, animals) is optimized for fuzzy approximation and instant pattern recognition. Our default option is not calculating but estimating.

Historically though, computers were built to do the exact opposite.

Remember High-School Math?

Given three coordinates $(x_{0}, y_{0})$ , $(x_{1}, y_{1})$ , and $(x_{2}, y_{2})$ : calculate quadratic function $f (x)$ that passes through those coordinates.

Now, consider the following data points.

x	y
0	1
1	2
2	4
3	8
4	16
5	???

Suppose I ask you to predict the value of y on x = 5.

Will you be surprised if I say that the answer is y = 31 ?

Sequences, sequences

Yes, it’s a trap. If you guessed 32, then you assumed the most elegant, underlying rule: $f (x) = 2^{x}$ .

In reality, those data points map to Moser’s circle problem (the maximum number of pieces formed when connecting points on a circle): a fourth-degree polynomial: $f (x) = \frac{1}{24} x^{4} - \frac{1}{12} x^{3} + \frac{11}{24} x^{2} + \frac{7}{12} x + 1$
_{Our data is shifted by one compared to the video’s, so we have to use substitute the x with x+1 instead}

Moral of the story? a dataset is only a fragment of reality. Mathematics allows us to fit an infinite number of perfect, elegant curves to any finite set of points. But most of them will fail to represent the physical reality.

“All models are wrong, but some are useful”
- George Box

The Software Engineer’s Illusion

This brings us to the classical “Software Engineer” mindset.

Historically, computer science adopted the mathematical illusion of absolute certainty. Just look at the flowchart - it’s a hard rule one after another.

We assumed that if we understood the fragment, we knew the exact, underlying rule. Because we believed we knew the rule, we built digital worlds using deterministic logic: state machines, lambda functions, and strict if-then-else trees.

In traditional programming, the software engineer is the supreme architect of reality. We write explicit instructions. For a banking application, the logic is closed and absolute:

if account_balance >= withdrawal_amount:
    approve_transaction()
else:
    reject_transaction()

And the machine does exactly what it is told. In this paradigm, $x$ explicitly yields $y$ . There is no ambiguity.

When Strict Rule Breaks

This deterministic approach works flawlessly for closed systems like corporate databases. But what happens when classical programming encounters the $y = 31$ scenario in the wild?

Well, we update the rule.
Discard $f (x) = 2^{x}$ and change it to $f (x) = \frac{1}{24} x^{4} - \frac{1}{12} x^{3} + \frac{11}{24} x^{2} + \frac{7}{12} x + 1$ .

But what if there’s another curveball?
This formula expects x=6, y=57, but what if the actual expected value is y=63 and the actual formula is $f (x) = 2^{x} - ⌊ \frac{x}{5} ⌋$ ?
Or y=62 with formula = $f (x) = 2^{x} - ⌊ \frac{2 ^{x}}{32} ⌋$ ?

We can keep chasing the “true” mathematical function, adding polynomial terms or plugging if-else exceptions for every new anomaly. For a 1D number sequence, that might eventually work.

But what happens when the input isn’t a neat integer, but a messy slice of the physical world?

Gotta Whack ‘em All!

Let’s consider the problem of identifying a handwritten number next. Try to write a deterministic program that identifies whether a 28x28 pixel image contains a handwritten number “3”. Output: simple TRUE - FALSE.

Let’s start with the classical engineering mindset, hardcoding the rules: If the top half has a curve, and the bottom half has a curve, it is a 3.

Then reality throws a curveball: What if the writer used a flat top, like the font on a bank check?
We patch the rule: if top_is_curved OR top_is_flat_with_diagonal...

Then the next curveballs arrive: What if the ink is smudged? What if the writer is left-handed and slanted it by 15 degrees? What if the entire image is shifted two pixels to the left?

These curveballs are infinite. If we try to account for every possible variation using deterministic if-else trees… It’s as if we’re playing an endless game of whack-a-mole, and that’s not even considering the maintenance cost of the code and technical debt!

Reject Order, Embrace the Noise (Moderately)

This is where machine learning begins. Statistics! Probability! Law of Averages!

Instead of trying to hardcode the exact, absolute boundaries of a concept, we collect thousands of examples, achieve inner peace by accepting that our model will never be flawless, and rely on the statistical promise of the law of averages.
_{And pray to whatever God you believe that the samples are representative enough for the target population.}

We allow the model to be wrong, so long as it is useful most of the time.

Previous: Humans and Pattern Recogniton
Next: It’s All Numerical Optimization

Quartz 5