Why Geometry & Trigonometry Matters for Programmers
Geometry & Trigonometry
Chapter 1 · Why Geometry & Trigonometry Matters for Programmers
Linear Algebra Fundamentals built vectors, matrices, and — briefly, in its own Chapter 5 — a first rotation matrix. Calculus & Optimization differentiated sin and cos without dwelling on what they actually measure. This course puts geometry itself in the foreground: the practical trigonometry and spatial reasoning behind graphics, game development, and computer vision, where a genuinely small mistake — like the one below — turns into a very visible bug.
A Real Bug: Subtracting Angles the Naive Way
A compass heading of 350° needs to turn toward a target heading of 10°. The obvious calculation is target − current:
10 − 350 = −340 degrees. Taken literally, this tells a robot or a game character to turn 340° the wrong way around, when the two headings are actually only 20° apart on the compass — 350° and 10° are close neighbors either side of due north, not far apart. The correct, wrapped difference — computed either by the standard modulo formula (target − current + 180) mod 360 − 180 or by the equivalent trigonometric identity atan2(sin(Δ), cos(Δ)) — gives exactly 20° both ways, confirmed directly.
This isn't a floating-point bug in the sense earlier Maths for Programmers courses covered — the arithmetic 10 − 350 is computed perfectly correctly. The bug is conceptual: angles wrap around, and ordinary subtraction doesn't know that. Recognizing where geometry has its own rules — rules that plain arithmetic doesn't automatically respect — is exactly what this course is about.
A Preview: The Dot Product Already Knows the Angle
Linear Algebra Fundamentals defined the dot product algebraically. Geometrically, it encodes an angle directly: cos(θ) = (a·b) / (|a||b|).
v1 = (1,0) and v2 = (1,1): v1·v2 = 1, |v1|=1, |v2|=√2, so θ = arccos(1/√2) = 45.00000000000001° — matching the geometrically obvious answer (a 45° diagonal) to floating-point precision. Chapter 4 builds this into a full, practical toolkit for angles-between-vectors, surface normals, and lighting calculations.
Five Concrete Connections to Real Code
| Geometry/trig topic | Where it actually shows up |
|---|---|
| Angle wraparound (Ch.2) | Compass headings, joystick input, character-facing logic — exactly this chapter's own verified bug |
| Dot/cross products (Ch.4) | Lighting (surface normal · light direction), collision detection, determining which side of a line a point is on |
| Rotation matrices & quaternions (Ch.5-7) | Every camera, character, and object orientation in a 3D game engine or robotics system |
| Coordinate transformations (Ch.8) | The camera/projection pipeline that turns a 3D scene into 2D pixels on screen |
| Intersection tests (Ch.9) | Mouse-picking, ray casting, collision detection between game objects |
What This Course Won't Cover
Geometry as a full mathematical field is enormous, and this course deliberately covers only what a working programmer building graphics, game, or computer-vision code actually needs:
- Formal, proof-based Euclidean geometry — axioms, theorems, and compass-and-straightedge constructions stay out of scope; this course treats geometry computationally and practically, not as classical proof
- Projective and non-Euclidean geometry — genuinely useful in specialized computer-vision and computer-graphics theory, but a deeper, more abstract topic than this course's own practical scope
- Differential geometry and manifolds — curvature, geodesics, and the formal machinery behind them belong to a more advanced, specialized course than this one
Where This Course Is Headed
| Chapter | Topic |
|---|---|
| 2 | Angles, Radians & the Unit Circle |
| 3 | Triangles: The Law of Sines, the Law of Cosines & Practical Trigonometry |
| 4 | Vectors & Dot/Cross Products in Geometric Context |
| 5 | 2D Rotations & Rotation Matrices |
| 6 | 3D Rotations: Euler Angles & Gimbal Lock |
| 7 | Quaternions |
| 8 | Coordinate Systems & Transformations |
| 9 | Geometric Primitives & Intersection Tests |
| 10 | Capstone — Building a Small 2D/3D Geometry Toolkit |
Hands-On Exercises
A drone's current heading is 5° and it needs to turn to face 340°. Using this chapter's own naive-subtraction bug and its own wrapped-difference formula, compute both the naive result and the correct result, and explain which direction the drone should actually turn.
Using this chapter's own dot-product angle formula, compute the angle between v1 = (0,1) and v2 = (1,0), and explain in your own words why the dot product alone — without also considering the cross product — cannot tell you whether v2 is rotated clockwise or counterclockwise from v1.
Using this chapter's own explanation of the heading-subtraction bug, explain why it is a "conceptual" bug rather than a floating-point precision bug of the kind covered in Numerical Methods & Floating-Point Computation — what specifically would (and wouldn't) get fixed by using a more precise numeric type?
📄 View solutionChapter 1 Quick Reference
- Verified: naively subtracting two compass headings (
10° − 350°) gives−340°, wildly wrong; the correct wrapped difference — via modulo oratan2(sin Δ, cos Δ)— is20° - Angle wraparound is a conceptual bug, not a floating-point precision bug — ordinary arithmetic doesn't know that angles repeat every 360°
- The dot product encodes angle directly:
cos(θ)=(a·b)/(|a||b|)— verified recovering exactly45°for two vectors forming a diagonal - Five direct connections: heading/input logic, lighting/collision via dot-cross products, 3D orientation via rotations/quaternions, camera/projection pipelines, mouse-picking/collision via intersection tests
- Deliberately out of scope: formal proof-based Euclidean geometry, projective/non-Euclidean geometry, differential geometry/manifolds
- Next chapter: Angles, radians, and the unit circle — the vocabulary every later chapter builds on