Coordinates and Points

Open Rhino, Revit, AutoCAD or SketchUp and, underneath the drawing, they all agree on the same quiet convention: a Cartesian coordinate system. There is an origin - the point (0, 0) - and from it you measure two directions, x running across and y running up. Any location on the plane is then fixed by two numbers: how far across, and how far up. The point (5, 3) means start at the origin, go 5 along x, then 3 along y. That is the entire idea, and it is the same one you used with graph paper in school.

The convention matters because it makes location computable. Once a place is two numbers instead of a spot you point at with a mouse, a program can store it, compare it, move it and measure it. A drawing becomes data. Everything else in this module - vectors, curves, meshes, the geometry algorithms - is built on this one agreement about what a location is.

One detail worth fixing early: in mathematics and in most CAD, y increases upward and angles turn anticlockwise. Some screen and image systems flip y so it grows downward, which is why a shape can appear upside-down when you move between contexts. It is not a mistake in your maths - just a different convention about which way is up. Knowing the axis directions of the tool you are targeting saves a lot of confused debugging later.

Designers already think this way without naming it. A setting-out drawing gives dimensions from a reference corner; a survey gives eastings and northings; a façade panel is placed so many millimetres over and so many up from a datum. Each is a Cartesian coordinate in disguise. When you script geometry you are simply making that habit explicit and handing it to the computer, which is tireless about the arithmetic you would rather not do by hand.

In Python a point is not a special object you have to import - it is just numbers held together in one of the containers you already met in Module 2. The three natural choices are a tuple, a list, and a dictionary, and the difference between them is really a difference of intent.

p_tuple = (5, 3)          # fixed: a point that will not change
p_list  = [5, 3]          # editable: same idea, but mutable
p_dict  = {"x": 5, "y": 3}  # labelled: clear names instead of positions

print(p_tuple[0], p_tuple[1])   # 5 3
print(p_dict["y"])              # 3

Most geometry code uses tuples for points, for two good reasons. A tuple is immutable - once made it will not change by accident, which is exactly what you want for a fixed location - and its shape reads clearly: (x, y) in 2D, (x, y, z) in 3D. You reach into it by position, so p[0] is x and p[1] is y.

A dict is worth it when the labels earn their keep - a point that also carries data, say {"x": 5, "y": 3, "level": "ground", "tag": "C4"} for a column. Then names beat remembering that index 3 was the tag. There is no single right container; there is only the one that makes your particular script clearest. A quick habit that pays off: unpack a point into named variables the moment you use it, so the maths reads plainly.

point = (5, 3)
x, y = point          # unpack into names
print(x + y)          # 8

The first genuinely useful thing you can compute from points is the distance between them - the straight-line length from one to the other. It comes straight from Pythagoras: the distance is the square root of the horizontal gap squared plus the vertical gap squared. In code you never write the square root by hand, because the standard library has math.hypot, which does exactly this and handles the awkward numeric edge cases for you.

import math

a = (2, 3)
b = (7, 15)
dx = b[0] - a[0]        # horizontal gap: 5
dy = b[1] - a[1]        # vertical gap: 12
dist = math.hypot(dx, dy)   # sqrt(5*5 + 12*12) = 13.0
print(round(dist, 2))       # 13.0

Because you will want this again and again, wrap it in a small function. This is the single most reused piece of geometry code you will write, and giving it a name makes every later script read better.

import math

def distance(a, b):
    return math.hypot(b[0] - a[0], b[1] - a[1])

print(distance((0, 0), (3, 4)))     # 5.0
print(distance((1, 1), (1, 6)))     # 5.0

With distance in hand you can already answer real questions: is this door within reach of that socket, which of these trees is nearest the boundary, how long is a setting-out line. Notice too that the function does not care about units - if your coordinates are in metres it returns metres, in millimetres it returns millimetres. Keeping your whole script in one unit is a discipline worth adopting early; mixing them is one of the most common sources of silently wrong geometry.

There is one performance habit worth knowing even now. When you only need to compare distances - to find which point is nearest, say - you can skip the square root entirely and compare the squared distances (dx*dx + dy*dy), because whichever is smaller squared is also smaller un-squared. The square root is a small cost, but in a loop over thousands of points that saving adds up, and it is a trick you will see in real geometry libraries. For everyday scripts, reach for the clear distance function first; keep the squared shortcut in your back pocket for when speed genuinely matters.

One point is an address. The power arrives when you generate many points from a rule - and a rule repeated is exactly what a loop is for. A regular grid is the simplest and most useful example: think of column positions, a setting-out grid, paving units, or sample points across a site. Two nested loops - one for rows, one for columns - place every point.

points = []
for row in range(3):
    for col in range(4):
        points.append((col * 2.0, row * 2.0))

print(len(points))          # 12
print(points[0], points[-1])  # (0.0, 0.0) (6.0, 4.0)

The outer loop steps down the rows; for each row the inner loop walks across the columns, and at every stop it appends one point. Multiply the spacing (2.0 here) and you change the grid module; change the range values and you change how many bays. The same six lines produce a 3x4 grid or a 30x40 grid - that is the leverage from Lesson 0.1, now aimed at geometry.

A more Pythonic way to write the same thing is a list comprehension, which many computational designers prefer once the shape is familiar:

grid = [(col * 2.0, row * 2.0)
        for row in range(3)
        for col in range(4)]
print(len(grid))   # 12

Either form gives you a list of points you can now transform, measure or draw. In Rhino or Grasshopper (Module 6) this exact list becomes real geometry with one more call; here the point is that the thinking - a rule, repeated over a range - is already complete, and it is pure Python.

The grid is only the beginning of rule-driven placement. Swap the arithmetic inside the loop and the same structure gives you a diagonal, a staggered brick-bond pattern, or points along a circle - anything you can express as a formula of the loop counters. That is the real lesson hiding in a humble nested loop: once positions come from a rule rather than from clicking, changing the design means changing one number, and the hundreds of points update themselves.

Everything so far was 2D, but stepping into three dimensions costs almost nothing conceptually: you add a third number, z, for height. A point becomes (x, y, z), the origin is (0, 0, 0), and distance gains one more squared term - which math.hypot handles happily, since it accepts any number of arguments.

import math

def distance3d(a, b):
    return math.hypot(b[0] - a[0], b[1] - a[1], b[2] - a[2])

floor = (0, 0, 0)
light = (3, 4, 12)
print(distance3d(floor, light))   # 13.0

The habit of unpacking still works - x, y, z = point - and a grid of points in 3D is just one more nested loop for the levels. This is why the atom matters so much: learn to handle a point cleanly and 2D versus 3D stops being a wall and becomes a single extra coordinate.

It is worth being honest about where the maths does get heavier later. Rotating in 3D, orienting a panel to a surface, or projecting a point onto a plane brings in trigonometry and matrices, which the next lesson opens gently. But a surprising amount of real design scripting - schedules of positions, nearest-neighbour checks, setting-out, simple layouts - never needs more than points, distance and a loop. Get comfortable here and you already have a genuinely useful geometric toolkit, before a single sine or cosine appears.

One last habit to build from the very start: give your coordinates meaning through good names and small helper functions. A tuple (5, 3) says nothing on its own, but a well-named variable - door_hinge, corner_ne, sample_points - turns a wall of numbers into readable geometry. The computer does not care, but the designer reading the script in three months certainly will, and that designer is usually you.