An array is a row of equal-size boxes placed side by side in memory , so the computer can jump straight to box number i using a tiny arithmetic formula instead of searching. Every superpower — instant access, cache speed, cheap appending — is just a consequence of "same size + side by side."
Before you can derive anything in the parent note , you need to fully own every word and symbol it throws at you. This page builds each one from nothing. Read top to bottom — each block earns the next.
Definition Memory & address
Computer memory is one gigantic single-file line of numbered slots, each slot holding one byte (one small chunk of data). The address of a slot is just its position number in that line — like a house number on an infinitely long street.
Picture memory as a ruler laid flat: position 0, 1, 2, 3, … going right forever. When we say a piece of data "lives at address 1000", we mean it sits at the 1000th tick on that ruler.
B
The address of the first slot of our array — where the whole block begins . We call it B (for B ase). Everything in the array is measured relative to B .
Why the topic needs it: the parent's headline formula addr ( i ) = B + i ⋅ s starts from B . Without a fixed starting tick, "element i " has no meaning — you need a place to start counting from.
s
Every value we store takes up a fixed number of bytes — its size , written s . An int is often s = 4 bytes; a double is s = 8 . In one array, every element has the same s .
Picture each array element as an identical box of width s ticks on the memory ruler. Same width, no gaps.
Intuition Why "same type / same size" is the whole game
If boxes had different widths, you couldn't predict where box 5 begins without walking past boxes 0–4 to add up their widths. Equal width is exactly what lets you multiply instead of walk . That single constraint is the seed of O(1) access.
Why the topic needs it: s is the step between neighbours. It appears in the address formula (i ⋅ s ) and again in the cache formula (L / s ).
i
The index is which box you mean, counted starting at 0 . Box 0 is the first, box 1 the second, … box n − 1 the last. The letter i is just a placeholder for "some box number".
Common mistake "The first element is number 1."
Why it feels right: humans count 1, 2, 3.
The fix: arrays count offsets from the base . Box 0 sits at B + 0 ⋅ s = B — zero steps from the start. So the first box is index 0, and the formula stays clean. If you started at 1, you'd need B + ( i − 1 ) s everywhere — uglier and error-prone.
Why the topic needs it: the range 0 … n − 1 and the term "index" appear in the array definition, in arr[5], and in every trace.
n (element count)
n is simply how many elements are in the array right now. The valid indices are 0 through n − 1 , which is exactly n boxes.
Why the topic needs it: "O(1) regardless of n " is the punchline of array access. And n is the yardstick every cost is measured against (O(1), O(n), O(n^2)).
Now that B , s , and i exist as pictures, the parent's formula reads itself:
Intuition Why this tool: multiply, not a loop
We could walk box by box (a loop, O(n) steps). But because every step is the identical size s , repeated addition collapses into one multiplication i ⋅ s . Multiplication answers "how far is i equal steps?" in a single machine operation — that's the whole reason access is O(1).
Two counts that look alike but mean different things — the parent leans on both.
Definition size and capacity
size = how many boxes you've actually filled with your data.
capacity = how many boxes are currently painted/reserved in memory, ready to receive data.
Always capacity ≥ size : you can't fill more boxes than exist.
Picture a row of 8 reserved boxes where only the first 3 hold values: capacity = 8 , size = 3 . The 5 trailing boxes are real memory, just empty.
Common mistake "size and capacity are the same thing."
Why it feels right: in a full array they're equal.
The fix: the gap between them is precisely what makes a cheap append possible — a spare box to write into without asking memory for more. When the gap hits zero (size = capacity ), you're forced into the expensive resize.
g
When a full array must grow, it makes a new block g times bigger. Doubling means g = 2 ; a common alternative is g = 1.5 . The parent's total-copy proof assumes g = 2 .
Why the topic needs it: whether append is O(1) amortized or O(n) amortized depends entirely on g being multiplicative (g > 1 , a factor) versus additive (+1, a constant). This one choice is the hinge of Section 3.
Definition Big-O — the growth-shape symbol
O ( ⋅ ) describes how the work grows as n grows , ignoring constant factors.
O ( 1 ) = flat — same cost no matter how big n is.
O ( n ) = straight line — double the data, double the work.
O ( n 2 ) = steep curve — double the data, quadruple the work.
Intuition Why we ignore constants
A step that always takes "3 operations" and one that takes "50 operations" are both O ( 1 ) — flat is flat. Big-O asks only about the shape of the growth, because for large n the shape dominates everything else. See Big-O Notation for the full story.
Why the topic needs it: every claim in the parent is a Big-O claim — access O ( 1 ) , resize O ( n ) , bad growth O ( n 2 ) .
Definition Amortized cost
The average cost per operation across a long run , when a few operations are expensive but most are cheap. Total work over n operations, divided by n .
Most appends are cheap O ( 1 ) writes; once in a while one is an expensive O ( n ) copy. Instead of judging append by its worst single moment, we spread ("amortize") the rare expensive cost thinly across all the cheap ones. The details live in Amortized Analysis .
Why the topic needs it: "O ( 1 ) amortized append" is the parent's central, most-misunderstood claim.
Definition Geometric series
A sum where each term is a fixed multiple of the previous one. Doubling gives 1 + 2 + 4 + 8 + ⋯ + 2 k . Its remarkable property: the sum is less than twice the last term .
Why the topic needs it: this is the engine of the amortized proof — total copy work < 2 n comes straight from this sum. More at Geometric Series .
L
When the CPU reads memory, it never grabs one byte — it grabs a whole line of L bytes (commonly L = 64 ) into fast cache at once. So reading one array element drags its neighbours along for free.
Picture the memory ruler chopped into fixed 64-tick chunks; touching any tick loads its entire chunk.
Why the topic needs it: L / s = elements per fetch is the parent's cache-locality formula. Contiguity means those neighbours are the very ones you'll read next . Background: CPU Cache and Memory Hierarchy .
Each box on the left is defined on this page; together they feed the parent topic on the right.
You are ready for the parent note when you can answer each without peeking:
What does the base address B represent? The memory address of the array's first element (box 0).
What is the element size s and why must it be constant across the array? Bytes each element occupies; constant s lets you compute box positions by multiplying instead of walking.
Starting index of an array, and why? 0 — so box i sits at B + i ⋅ s with no correction term.
What is n ? The number of elements currently stored; valid indices 0 … n − 1 .
State the address formula and read it in words. addr ( i ) = B + i ⋅ s : start at base B , skip i boxes of width s .
Difference between size and capacity? size = boxes filled; capacity = boxes reserved; capacity ≥ size.
What is the growth factor g and which value must it beat? The multiplier for a new block on resize; it must be > 1 (multiplicative), e.g. 2, not additive +1.
What do O ( 1 ) , O ( n ) , O ( n 2 ) mean as shapes? Flat, straight line, steep upward curve of work versus n .
Define amortized cost in one sentence. Total cost over many operations divided by the number of operations, spreading rare expensive steps over cheap ones.
Value of 1 + 2 + 4 + ⋯ + 2 k ? 2 k + 1 − 1 , which is less than 2 ⋅ 2 k .
What is a cache line L and how many elements fit per fetch? A ~64-byte chunk loaded at once; L / s elements per fetch.
"B, s, i pick the box; size vs cap picks the fight; g , geo, amortized win it."