Foundations — Vectorization — avoiding Python loops, speed comparison

Before you can feel why vectorization wins, you must be able to read every symbol the parent note throws at you. This page builds each one from nothing — plain words first, then a picture, then why the topic needs it.

0. What is a "number in memory" anyway?

Everything below rests on one fact: how a value is stored decides how fast you can use it.

The picture: think of memory as a long ruler marked off in tiny cells. A float64 occupies 8 consecutive cells and nothing extra.

Why the topic needs it: the whole speed story is "packed raw numbers vs. scattered boxed objects." You cannot understand the difference until you can see what "packed raw" looks like on the ruler. See NumPy Arrays vs Python Lists for the full comparison.

1. A boxed object vs. a raw value

The picture: a raw float64 is a bare number on the ruler. A boxed number is that value hidden inside a cardboard box, and the box sits somewhere else in memory with a string tied from your list to the box.

Why the topic needs it: the parent note lists the loop's four costs — fetch object, check type, dispatch method, allocate new object. Every one of those exists only because the number is boxed. Remove the box (use a NumPy array) and all four costs vanish.

2. $N$ — the count of elements

The picture: $N$ is the length of the row on the ruler.

Why the topic needs it: the cost of a loop is "cost-per-item × number-of-items." That multiplication is where slowness compounds. $N$ is the multiplier.

3. Time and its units — ns, ms, s

The picture: a bar chart of shrinking blocks, each 1000× thinner than the last.

Why the topic needs it: the parent quotes "${\tau }_{\text{py}}\approx 100$ ns" and "${\tau }_{\text{vec}}\approx 1$ ns." Those numbers are meaningless unless you know a nanosecond is a billionth of a second, so a million of them is only $10^6\times 10^{-9}=10^{-3}$ s = 1 ms.

4. $\tau$ (tau) and $c$ — cost per element and fixed setup

The picture: imagine two receipts. One (setup) is a flat entry fee. The other grows one line per item.

Why the topic needs it: the entire time model $T=c_{\text{setup}}+N\cdot \tau$ is just "flat fee plus per-item fee times number of items." Every symbol you now know:

5. The ratio, the limit, and the $\to$ arrow

Why the topic needs it: the headline "$\approx 100\times$" is a limit. As $N\to \infty$, the fixed $c_{\text{setup}}$ becomes a rounding error, so $\text{Speedup}=\frac{N{\tau }_{\text{py}}}{c_{\text{setup}}+N{\tau }_{\text{vec}}}⟶\frac{{\tau }_{\text{py}}}{{\tau }_{\text{vec}}}.$ The $N$'s cancel because both top and bottom grow in step; only the per-element ratio survives.

6. Big-O — one word for "how cost scales"

The picture: a straight line ($O(N)$) versus an upward-curving parabola ($O(N^2)$).

Why the topic needs it: the parent's biggest trap — np.append inside a loop — is bad precisely because it turns an $O(N)$ job into $O(N^2)$: each append copies the whole array, so total copying is $1+2+\cdots +N\approx N^2/2$. You need Big-O to see why that's catastrophic. Full detail in Big-O Complexity.

7. Vocabulary that rides along

Why the topic needs it: these are the verbs of vectorization. Every "FAST" code block in the parent is one of them: arithmetic → ufunc, + across shapes → broadcasting, a[a<0]=0 → mask.

The prerequisite map

Read it top-down: memory layout and counting feed the cost model; the cost model plus units give the speedup limit; Big-O explains the mistakes; the named tools are how you actually do it.

Equipment checklist

Tick each only when you can answer without peeking.