Vectors as Coordinates

Every time your phone drops a pin on a map or a game drops a character onto the screen, some location has to be stored as plain numbers a computer can add and compare. "Three streets east and two north" is far easier to work with than "that way, about a kilometre." Vectors get the same upgrade here: we swap arrows for pairs of numbers.

"A length and an angle" describes a vector, but it's awkward to compute with. There's a tidier way. On the coordinate plane, any arrow from the origin is fixed by where its head lands. So we can describe the whole vector with just two numbers: how far it goes across and how far it goes up.

These two numbers are the vector's components. We stack them in a column:

\vec{v} = \begin{bmatrix} v_x \\ v_y \end{bmatrix}.

For example \begin{bmatrix} 3 \\ 2 \end{bmatrix} means "go 3 right, then 2 up." Here's the useful secret: those are the exact same two numbers you'd write down for "the point 3 across and 2 up." A vector and a point can share identical coordinates — (3, 2) might mean "the arrow that gets you there from the origin," or it might just mean "the dot sitting there." One pair of numbers, two jobs. That double meaning is one of the most useful — and most trip-worthy — ideas in the whole subject, and it's the bridge linear algebra is built on.

Why bother having two names for the same thing? Because each reading is good at a different job. Thinking of (3, 2) as a point is perfect for asking "where is it?" — is it inside this shape, how far is it from that landmark, does it sit on this line? Thinking of the very same numbers as a vector is perfect for asking "how do I get there, and what happens if I combine this move with another one?" Keep both readings in your pocket and swap between them whenever one makes the problem easier.

Reading off the components

Steer the head of the vector below. The dashed legs show its two components — the across step v_x and the up step v_y — and the column updates to match. Every arrow you can draw has exactly one such pair, and every pair draws exactly one arrow. Push the head into the left half of the plane and watch v_x turn negative rather than the arrow breaking — the sign is simply telling you which way along that axis the step goes.

Points, displacements, and the zero vector

A vector \begin{bmatrix} 3 \\ 2 \end{bmatrix} can name a position (the point at (3, 2), measured from the origin) or a displacement (the move "3 right, 2 up" from wherever you happen to be standing). When it names a position, we sometimes write it as \vec{OP} — the arrow from the origin O out to the point P — to make the "measured from the origin" part explicit.

The special vector \vec{0} = \begin{bmatrix} 0 \\ 0 \end{bmatrix} is the zero vector: no length, no direction, an arrow that goes nowhere — it's also the position vector of the origin itself. And nothing forces us to stop at two components — a vector in three dimensions has three, and a data point with 100 features is a vector with 100 components. The picture stops at 3D; the arithmetic never does.

This is also why the position/displacement split matters so much once you leave 2D. Nobody can draw a picture of a 100-component arrow, but "subtract two position vectors to get the displacement between them" still means exactly the same thing whether you're working in the plane or in a 100-dimensional space of, say, a customer's shopping habits. The components-as-a-list idea is what lets the arithmetic travel to places the picture can't follow.

Worked example: from two points to a displacement

Suppose a robot starts at point A = (2, 5) and needs to drive to point B = (9, 1). First write each point as a position vector measured from the origin:

\vec{OA} = \begin{bmatrix} 2 \\ 5 \end{bmatrix}, \qquad \vec{OB} = \begin{bmatrix} 9 \\ 1 \end{bmatrix}.

The robot doesn't care where the origin is — it needs the displacement that carries it from A straight to B. That's exactly the difference of the two position vectors:

\vec{AB} = \vec{OB} - \vec{OA} = \begin{bmatrix} 9 - 2 \\ 1 - 5 \end{bmatrix} = \begin{bmatrix} 7 \\ -4 \end{bmatrix}.

Drive 7 right and 4 down and the robot lands exactly on B. Notice this displacement is a completely different kind of vector from \vec{OA} or \vec{OB} — it isn't anchored to the origin at all, and it would be exactly the same arrow if A and B were shifted somewhere else on the plane together.

Worked example: the origin can move, the displacement can't

Here's a check that displacement really is origin-independent. Keep the same robot points A = (2, 5) and B = (9, 1), but this time measure everything from a different origin — say a new reference point O' = (10, 10), marked on the warehouse floor instead of the usual corner. The position vectors change completely:

\vec{O'A} = \begin{bmatrix} 2 - 10 \\ 5 - 10 \end{bmatrix} = \begin{bmatrix} -8 \\ -5 \end{bmatrix}, \qquad \vec{O'B} = \begin{bmatrix} 9 - 10 \\ 1 - 10 \end{bmatrix} = \begin{bmatrix} -1 \\ -9 \end{bmatrix}.

Subtract them exactly as before to get the displacement from the new origin's point of view:

\vec{AB} = \vec{O'B} - \vec{O'A} = \begin{bmatrix} -1 - (-8) \\ -9 - (-5) \end{bmatrix} = \begin{bmatrix} 7 \\ -4 \end{bmatrix}.

Exactly the same answer as before, (7, -4) — even though every position vector involved changed completely. That's the whole point of calling \vec{AB} a displacement rather than a position: it only cares about the relationship between A and B, never about where you decided to plant the origin.

Worked example: the centre of a shape

Position vectors also make shapes easy to compute with. Take a triangle with corners P_1 = (0, 0), P_2 = (6, 0), and P_3 = (3, 6) — each corner is just a position vector from the origin. To find the triangle's centre (its centroid), average the three position vectors component by component:

\text{centre} = \frac{1}{3}\left( \begin{bmatrix} 0 \\ 0 \end{bmatrix} + \begin{bmatrix} 6 \\ 0 \end{bmatrix} + \begin{bmatrix} 3 \\ 6 \end{bmatrix} \right) = \frac{1}{3}\begin{bmatrix} 9 \\ 6 \end{bmatrix} = \begin{bmatrix} 3 \\ 2 \end{bmatrix}.

The centroid (3, 2) sits inside the triangle, balanced between all three corners — this is the same "add them up and scale" move from linear combinations, just with all three weights set to \tfrac{1}{3}. Video-game engines use exactly this trick to find the middle of any polygon, from a triangle to a thousand-sided monster hitbox.

Real-world hook: GPS is position vectors

Your phone's GPS doesn't know "north" and "east" in some mystical sense — it works entirely with position vectors. Pick a reference origin (a survey marker, or just "wherever you started"), and every location becomes a vector of how far east and how far north it sits from that origin, typically in metres or kilometres. Two hikers' phones can compare their position vectors and instantly compute the displacement between them by subtracting — exactly the robot calculation above, just with GPS coordinates standing in for (x, y).

Say your tent sits at position vector (1.2, 3.4) km east/north of base camp, and the summit sits at (0.4, 6.9) km from that same base camp. The hiking app doesn't need to know anything about base camp at all to tell you the walk ahead — it just subtracts: (0.4 - 1.2,\ 6.9 - 3.4) = (-0.8, 3.5) km, meaning "0.8 km west, then 3.5 km north" from the tent to the summit. Change which mountain range you're using as "base camp zero" and every position vector on the map would shift — but that walking instruction would come out exactly the same, for the same reason it did in the worked example above.

A "free" displacement vector can be slid anywhere in the plane without changing its meaning — only its length and direction matter. A position vector is different: it is defined as the arrow from the origin to a point, so its whole job is to say "here is where this point is, relative to that one fixed spot." Slide it away from the origin and it stops being that point's position vector — it's now just some arrow floating in space.

The second trap is mixing up a point's coordinates with a displacement's coordinates, because they can look identical as ordered pairs. If a hiker is standing at (4, -2) km from base camp, that's a position. If two other hikers are (4, -2) km apart from each other, that's a displacement — a completely different fact, expressed with the exact same numbers. Always ask: is this pair of numbers telling me where something is, or how far and which way to move? The symbols don't tell you; the context does.

A good habit that catches both traps at once: whenever you write a vector down, silently ask yourself "from where?" If the honest answer is "from the origin, always," you're holding a position vector and it must stay anchored there. If the honest answer is "it doesn't matter, from anywhere," you're holding a free displacement and you're safe to slide it around the page.

Open any image and zoom in far enough, and you'll find every pixel labelled by a pair of numbers — say, "pixel (120, 340)." That's a position vector, measured from a fixed origin sitting in the top-left corner of the screen (with "down" often counted as positive, which trips up more than one beginner programmer). Every button, letter, and photo you see is a swarm of position vectors telling the screen exactly where to light up.

This is also what "vectorising" an image in graphics software really means. A bitmap photo stores a colour for every single pixel position. A vector graphic instead stores just the handful of position vectors at a shape's corners (plus curve instructions) — so a logo built from vectors can be blown up to the size of a billboard with perfectly crisp edges, while a bitmap photo blown up the same way turns to mush.