A comprehensive guide for software engineers entering AV/ML/GPS — assumes minimal math background
You write code for a living. You think in logic, loops, and data structures. This guide translates math into that mindset — every concept is grounded in something physical you can picture, and connected to the AV/ML systems you want to understand.
Algebra → Functions → Limits → Exponents & Logs → Derivatives → Integrals → Diff Equations → Systems → Numerical Methods → Control → Statistics → Kalman Filter
Algebra is just using letters to represent unknown numbers, then finding those numbers using rules. You already do this in code: let x = totalPrice / quantity. Math does the same thing.
A variable is a placeholder for a number you don't know yet (like a function parameter). An expression is a recipe that uses variables:
Multiplication is often written without a sign: $3x$ means $3 \times x$. Parentheses work like code: evaluate the inside first.
An equation says two expressions are equal. Solving means finding what value of the variable makes it true.
Worked example: Solve $3x + 7 = 22$
Worked example: Solve $\frac{v - v_0}{a} = t$ for $v$
This is the velocity equation from physics. You just derived it by rearranging.
Solve $ax + b = c$ — enter coefficients and check your answer.
Math uses subscripts to label related variables: $v_0$ means "the initial velocity", $v_f$ means "the final velocity". They're just names — like v_initial and v_final in code.
Greek letters are used because we run out of Roman ones:
This is literally a for-loop:
In code: let sum = 0; for (let i = 1; i <= 5; i++) sum += i*i;
Surveyors collect $N$ GPS readings and average them to reduce noise:
This is just algebra + summation. With 100 readings, the average position is ~10× more precise than a single reading. The $\frac{1}{N}$ in front and the $\Sigma$ are the only "math" — the rest is collecting data.
A function is a machine that takes an input and produces exactly one output. In code, it's literally a function:
function f(x) { return x*x + 1; }The input variable (here $x$) is called the independent variable. The output $f(x)$ is the dependent variable (it depends on what you feed in). We often write $y = f(x)$.
A graph is a picture of all input-output pairs. The x-axis is the input, the y-axis is the output. Every point $(x, y)$ on the curve satisfies $y = f(x)$.
A straight line. $m$ = slope (rise/run), $b$ = y-intercept (where it crosses the y-axis). Constant rate of change.
Example: distance = speed × time. If speed is constant, distance is linear in time.
A parabola (U-shape or ∩-shape). The rate of change itself is changing.
Example: distance under constant acceleration: $d = \frac{1}{2}at^2$.
Grows (or decays) by a constant percentage each step. The most important function in engineering — covered in depth next section.
Oscillates forever between $-A$ and $A$. $A$ = amplitude (height), $\omega$ = angular frequency (speed of oscillation), $\phi$ = phase shift (horizontal offset). Everything that repeats — waves, vibrations, AC power, wheel rotation, seasonal patterns — is modeled with sine and cosine.
Example: A wheel spinning at $\omega = 10$ rad/s traces $y = r\sin(10t)$. An AC outlet delivers $V(t) = 170\sin(120\pi t)$ — a 60 Hz oscillation with 170 V peak. More detail in the trig guide.
Pick a function type and adjust parameters. See how the graph changes.
If $f(x) = x^2$ and $g(x) = x + 3$, then $f(g(x)) = f(x+3) = (x+3)^2$. This is like piping in Unix: the output of $g$ becomes the input of $f$. In AV systems, sensor data flows through chains of functions: raw signal → filter → transform → estimate.
A thermistor outputs resistance $R$. The processing pipeline is a chain of functions:
Each arrow is a function. The full pipeline is $f_4(f_3(f_2(f_1(R))))$ — function composition. Every sensor in an AV has a similar pipeline, and understanding what each function does (and can go wrong) is core to sensor engineering.
Before we can define derivatives or integrals, we need one key idea: what value does a function approach as the input gets close to some number? This is a limit — the mathematical tool for handling "infinitely close" without actually dividing by zero.
What is $f(x) = \frac{x^2 - 1}{x - 1}$ when $x = 1$? Plugging in gives $\frac{0}{0}$ — undefined. But watch what happens as $x$ gets close to 1:
Why? Factor the numerator: $\frac{x^2-1}{x-1} = \frac{(x-1)(x+1)}{x-1} = x + 1$ (when $x \neq 1$). As $x \to 1$, this approaches $1 + 1 = 2$. The function has a "hole" at $x = 1$, but the limit fills it in.
"As $x$ gets arbitrarily close to $a$ (but not equal to $a$), $f(x)$ gets arbitrarily close to $L$."
The function doesn't need to be defined at $a$ — limits care about what happens near $a$, not at $a$. This is exactly the situation with derivatives: we divide by $h$, then let $h \to 0$.
If plugging in gives a real number (no $0/0$, no blowup), that's your answer:
Worked example: $\displaystyle\lim_{x \to 2}\frac{x^2 - 4}{x - 2}$
Worked example: $\displaystyle\lim_{x \to 0}\frac{\sqrt{x+4}-2}{x}$
What happens as $x$ grows without bound? The highest-power terms dominate:
For $\frac{3x^2+5x}{x^2+1}$: divide top and bottom by $x^2$ → $\frac{3+5/x}{1+1/x^2} \to \frac{3}{1}$. Same idea as Big-O: keep the dominant term.
If $g(x) \le f(x) \le h(x)$ near $a$, and $\lim_{x\to a} g(x) = \lim_{x\to a} h(x) = L$, then $\lim_{x\to a} f(x) = L$ too. The function is "squeezed" to the limit. This is how the most important trig limit is proven.
Even though $\sin(0)/0$ is undefined, the ratio approaches exactly 1. Proven by squeezing: $\cos x \le \frac{\sin x}{x} \le 1$ near $x = 0$. This single limit is why $\frac{d}{dx}\sin x = \cos x$ — it's the foundation of all trig calculus.
Used to derive $\frac{d}{dx}\cos x = -\sin x$. Together with the sinc limit, these two unlock every trigonometric derivative and integral.
Covered in depth in the next chapter — the natural base of growth and decay.
No matter how large $n$ is, $e^x$ eventually dwarfs $x^n$. This is why $O(2^n)$ algorithms are impractical and why exponential decay kills any polynomial signal.
Sometimes a function approaches different values from the left vs right:
Since left ≠ right, $\lim_{x \to 0}\frac{1}{x}$ does not exist. A two-sided limit exists only when both one-sided limits agree. In engineering: $\tan(\theta)$ blows up at $\theta = \pi/2$ (90°) — important when computing steering angles near full lock.
A function is continuous at $x = a$ if: (1) $f(a)$ exists, (2) $\lim_{x\to a}f(x)$ exists, and (3) they're equal. No holes, no jumps, no blowups.
Polynomials, $e^x$, $\sin x$, $\cos x$ are continuous everywhere. Rational functions like $\frac{1}{x}$ are continuous except where the denominator is zero. $\tan(x) = \frac{\sin x}{\cos x}$ is continuous except at $x = \frac{\pi}{2} + n\pi$ (where $\cos = 0$).
Watch what value $f(x)$ approaches as $x$ gets close to the critical point. The hollow circle shows where the function is undefined. Increase zoom to approach more closely.
In digital signal processing, the ideal reconstruction filter is the sinc function:
At $x = 0$, this is $0/0$, but $\lim_{x\to 0}\text{sinc}(x) = 1$. When your phone plays audio, it reconstructs a continuous waveform from discrete samples using sinc interpolation — the limit at zero is what makes the math work. This connects to the Nyquist theorem: to perfectly reconstruct a signal with frequencies up to $f$, you must sample at $\geq 2f$ Hz. GPS receivers, LiDAR sensors, and camera frame rates are all constrained by this limit-based result.
Every numerical derivative is an approximation of a limit:
const derivative = (f(x + h) - f(x)) / h; // h = 1e-8
You can't set $h = 0$ (division by zero). You make $h$ small and hope it's "close enough" to the limit. But there's a tradeoff: too large → truncation error (the limit isn't reached). Too small → floating-point cancellation ($f(x+h) - f(x)$ rounds to 0). The sweet spot is $h \approx \sqrt{\epsilon_{\text{machine}}} \approx 10^{-8}$ for 64-bit floats. Understanding limits tells you why this tradeoff exists.
This chapter is critical. Almost every differential equation solution involves $e^{something}$. You can't skip this.
Key rules (these are worth memorising):
Why exponents matter: They describe anything that grows or shrinks by a percentage. If a population doubles every hour: $P(t) = P_0 \cdot 2^t$. If a signal halves every second: $S(t) = S_0 \cdot (0.5)^t$.
A logarithm answers: "what power do I need?"
"$\log$ base $b$ of $x$ equals $y$" means "$b$ raised to $y$ gives $x$."
$\log_2(8) = 3$ because $2^3 = 8$
$\log_{10}(1000) = 3$ because $10^3 = 1000$
$\log_2(1) = 0$ because $2^0 = 1$
Think of it as the inverse function: exponent goes up, logarithm comes back down.
They undo each other — like encrypt(decrypt(msg)) = msg.
Log rules (mirror the exponent rules):
This is the most important number in calculus and engineering. Here's why it exists:
Imagine you invest $1 at 100% annual interest. How much do you have after 1 year?
$e$ is what you get when you compound continuously — it's the natural base of growth and decay.
The natural logarithm $\ln(x) = \log_e(x)$ is the log with base $e$. In code, Math.exp(x) = $e^x$ and Math.log(x) = $\ln(x)$.
See how $y = a \cdot e^{kx}$ behaves. Positive $k$ = growth, negative $k$ = decay.
Radio signal power decays exponentially with distance (in addition to inverse-square spreading). GPS signal attenuation through building walls:
where $\alpha$ is the attenuation constant of the material. Concrete has $\alpha \approx 0.4$/m — after 5 m of concrete, signal strength is $e^{-2} \approx 13.5\%$ of original. This is why GPS doesn't work indoors, and why autonomous vehicles must handle GPS-denied environments.
You're driving. Your odometer reads 100 km at 2:00 PM and 160 km at 3:00 PM. Average speed = $\frac{160-100}{1} = 60$ km/h. But were you going exactly 60 the whole time? Probably not — you sped up, slowed down, maybe stopped.
To know your speed at exactly 2:15 PM, you'd shrink the time interval: check at 2:15:00 and 2:15:01 (1 second). Even smaller: 2:15:00.000 and 2:15:00.001. The derivative is the limit of this process — the instantaneous rate of change.
This gives the average rate of change between two points. As $h$ gets smaller, the two points get closer, and the line becomes a tangent — touching the curve at exactly one point.
Worked example from scratch: Find the derivative of $f(x) = x^2$.
You don't go through the limit every time. Patterns emerge:
Why does $\frac{d}{dx}\sin x = \cos x$? It comes from the limit $\lim_{h\to 0}\frac{\sin h}{h} = 1$ (Chapter 2). That single limit powers all of trig calculus.
Worked example (trig + chain rule): A wheel of radius $R = 0.3$ m spins with angular position $\theta(t) = 5t$ rad. A point on the rim traces a circle: $x(t) = R\cos(5t)$, $y(t) = R\sin(5t)$. Find the velocity.
This is how AV wheel encoders work: measure $\theta(t)$, differentiate with trig to get x/y velocity components for dead reckoning navigation.
See $f(x)$, its derivative $f'(x)$, and the tangent line at any point. When the function is flat, the derivative is zero. When the function is steep, the derivative is large.
An ANPR (Automatic Number Plate Recognition) camera records your car's position at two points. Your average speed is the finite difference $\Delta x / \Delta t$. But your instantaneous speed (what a radar gun measures) is the derivative $dx/dt$. Autonomous vehicles compute derivatives of everything: rate of change of distance to the car ahead ($\frac{dD}{dt}$ — closing speed), rate of change of steering angle ($\frac{d\delta}{dt}$ — steering rate), rate of change of lateral position ($\frac{dy}{dt}$ — drift speed).
The integral is the reverse of the derivative. If the derivative chops a quantity into rates, the integral adds the rates back up to recover the quantity.
You have a graph of your car's speed over time. How far did you travel? Distance = speed × time. But speed keeps changing! So you chop time into tiny pieces $\Delta t$, multiply each by the speed at that moment, and add them up:
This is a Riemann sum — literally a for-loop. As $\Delta t \to 0$ and $N \to \infty$, the sum becomes exact:
$$\text{distance} = \int_{t_1}^{t_2} v(t)\,dt$$The integral symbol $\int$ is just a stretched "S" for "Sum". The $dt$ tells you what variable you're summing over.
Since integration is the reverse of differentiation, we ask: "what function, when differentiated, gives me this?"
$C$ is the "constant of integration" — because the derivative of any constant is 0, we don't know what constant was there.
Common antiderivatives (reverse the derivative table):
Worked example: $\int (6x^2 + 4x - 3)\,dx$
The Fundamental Theorem of Calculus: to find the area under $f$ from $a$ to $b$, find the antiderivative $F$, then compute $F(b) - F(a)$.
Worked example: Area under $f(x) = x^2$ from $x = 0$ to $x = 3$
Worked example (trig): Energy in one half-cycle of AC current: $\int_0^{\pi}\sin(x)\,dx$
In AC power, this integral gives energy per half-cycle. The full cycle $\int_0^{2\pi}\sin(x)\,dx = 0$ because positive and negative halves cancel — this is why AC needs rectification to charge a DC battery.
Watch the rectangles approximate the area. More rectangles = better approximation → integral in the limit.
Your car's odometer computes $\text{distance} = \int_0^T v(t)\,dt$ every moment. At each tick of the wheel speed sensor (say every 10 ms), the ECU does:
distance += speed * 0.01; // Euler integration (Riemann sum)
That's a Riemann sum with $\Delta t = 0.01$ s. The GPS receiver does the same with Doppler-derived velocities. Every position estimate on your phone is a running integral of velocity. Every velocity estimate is a running integral of acceleration. It's integrals all the way down.
Now we combine derivatives with equations. A differential equation (DE) is an equation containing derivatives. Instead of telling you a value, it tells you the rule by which a value changes.
const x = 5. A differential equation is like a loop that updates state: while(running) { x += -2*x*dt; }. You define the update rule, and the system evolves.
In the real world, we rarely know the answer directly. Instead, we know how things relate in the moment:
Worked example: $\frac{dv}{dt} = 9.8, \quad v(0) = 0$ (a ball dropped from rest)
Pick a real system. See its DE, the solution, and the curve. Think about why the curve has that shape.
Gradient descent updates weights: $w_{n+1} = w_n - \eta \frac{\partial L}{\partial w}$. In the continuous limit, this is a DE:
For a simple quadratic loss $L = w^2$, this becomes $\frac{dw}{dt} = -2\eta w$, whose solution is $w(t) = w_0 e^{-2\eta t}$ — exponential decay toward the minimum. The learning rate $\eta$ controls how fast. This is why training loss curves look like exponential decays — they literally are.
Two equations handle the vast majority of engineering. Let's solve them completely, no steps skipped.
This says: "the rate of change of $y$ is proportional to $y$ itself." Big $y$ → big change. Small $y$ → small change.
Full solution by separation of variables:
$k > 0$: exponential growth. $k < 0$: exponential decay. The half-life (time to halve) is $t_{1/2} = \frac{\ln 2}{|k|}$.
This says: "$y$ is being pulled toward the value $b/a$ at a rate controlled by $a$." Like a thermostat: the room is pushed toward the set temperature.
Full solution by integrating factor:
The time constant $\tau = 1/a$ is how long the transient takes to decay to ~37% of its initial value (or equivalently, how long to reach ~63% of the way to steady state).
Adjust $a$, $b$, $y_0$. Watch the solution curve. Orange dot = start. Dashed = steady state. Vertical line = time constant $\tau$.
Capacitor ($C = 100\,\mu$F) charges through resistor ($R = 10\,$kΩ) from 5V supply. Kirchhoff's voltage law gives:
This is Equation B with $a = 1/RC = 1/(10000 \times 0.0001) = 1$, $b = V_s/RC = 5$.
$\tau = RC = 1$ s. Steady state = $V_s = 5$ V.
After $1\tau$: 63% → 3.15V. After $3\tau$: 95% → 4.75V. After $5\tau$: 99.3% → 4.97V.
Raw GPS position $x_{\text{GPS}}$ jumps around. We want a smooth estimate $\hat{x}$. First-order filter:
Rearrange: $\frac{d\hat{x}}{dt} + \alpha\hat{x} = \alpha\, x_{\text{GPS}}$. This is Equation B with $a = \alpha$, $b = \alpha \cdot x_{\text{GPS}}$. The estimate exponentially approaches the GPS reading with time constant $\tau = 1/\alpha$. Large $\alpha$ → fast but noisy. Small $\alpha$ → smooth but laggy. This tradeoff is the central dilemma of all sensor filtering.
Real systems have multiple quantities changing at once, often affecting each other. A car has position AND velocity AND heading — all changing, all connected.
A single second-order DE can be split into two first-order DEs. Newton's law $F = ma$ means $m\frac{d^2x}{dt^2} = F$. Define $v = \frac{dx}{dt}$:
Now we have two first-order DEs instead of one second-order. This is always possible, and it's how computers actually solve higher-order DEs.
Pack all your variables into a state vector and write the system as a matrix equation:
For a car with drag: $\mathbf{x} = \begin{bmatrix} x \\ v \end{bmatrix}$, $A = \begin{bmatrix} 0 & 1 \\ 0 & -b \end{bmatrix}$, $B = \begin{bmatrix} 0 \\ 1/m \end{bmatrix}$, $u = F$
Row 1: $\dot{x} = 0 \cdot x + 1 \cdot v = v$ (position changes by velocity)
Row 2: $\dot{v} = 0 \cdot x + (-b) \cdot v + F/m$ (velocity changes by force minus drag)
Trig in state space: When a vehicle has heading angle $\theta$, position updates use trigonometry: $\dot{x} = v\cos\theta$, $\dot{y} = v\sin\theta$. The state vector becomes $[x, y, \theta, v]^T$. The $\cos$ and $\sin$ terms make this nonlinear — the "$A$ matrix" depends on the current state $\theta$. This is why real AV navigation uses the Extended Kalman Filter, which linearises trig functions at each time step using their derivatives ($\cos\theta \to -\sin\theta$, etc.).
A car with position and velocity. Adjust throttle and drag. Left: time plots. Right: phase portrait (state-space trajectory).
A real navigation filter tracks:
15 states. The $A$ matrix is 15×15 — 225 entries encoding how every state affects every other. But the structure is the same as our 2-state car: $\dot{\mathbf{x}} = A\mathbf{x} + B\mathbf{u}$. Understanding the simple case gives you the pattern for the complex one.
The core idea: a continuous curve is approximated by stepping forward in discrete time increments $\Delta t$ (just like game physics or animation frames).
"Current value + step size × current slope = next value"
Think of it as walking with a compass: check direction, walk straight for a bit, check again. With small steps it works. With big steps you drift off course.
In code:
let y = y0;for (let t = 0; t < tMax; t += dt) { y += dt * f(t, y);}
Instead of one slope sample, take four across the step and average them (weighted). This is dramatically more accurate.
In code:
function rk4Step(f, t, y, h) { const k1 = f(t, y); const k2 = f(t+h/2, y+h/2*k1); const k3 = f(t+h/2, y+h/2*k2); const k4 = f(t+h, y+h*k3); return y + h/6*(k1 + 2*k2 + 2*k3 + k4);}
Solve $dy/dt = -2y + 4$, $y(0) = 0$ (exact: $y = 2 - 2e^{-2t}$). Increase $\Delta t$ to see Euler fail while RK4 stays close.
GPS signal lost. The car's IMU (accelerometer + gyro) dead-reckons:
// Euler integration at 100 Hzvelocity += acceleration * 0.01;position += velocity * 0.01;
This is Euler's method on $\dot{v} = a$ and $\dot{x} = v$. At 100 Hz ($\Delta t = 0.01$ s), Euler works fine. But accelerometer noise accumulates (random walk) — after 30 s, position error can be metres. This is the fundamental reason GPS/INS fusion (Kalman filter) exists.
A control system is a DE with a feedback loop. It measures where you are, compares to where you want to be, and applies a correction. Your thermostat, cruise control, and every robot on Earth uses this pattern.
P (Proportional) — "The further I am, the harder I push." Steering: the more you're drifting from the lane center, the more you turn the wheel. Problem: can overshoot.
I (Integral) — "If I've been off for a while, push harder." A persistent crosswind pushes you right; the I term accumulates that bias and gradually adds leftward correction. Problem: can windup and cause sluggish oscillation.
D (Derivative) — "If I'm approaching the target fast, ease off." You're almost at the right lane position but zooming toward it — D applies braking. Problem: amplifies noise in measurements.
Trig connection: In vehicle control, steering angle $\delta$ changes heading via $\dot{\theta} = \frac{v}{L}\tan(\delta)$ (bicycle model, $L$ = wheelbase). The PID output becomes $\delta$, which through $\tan$, $\sin$, $\cos$ propagates into position changes: $\dot{x} = v\cos\theta$, $\dot{y} = v\sin\theta$. Trig is the bridge between control output and physical motion.
A mass must reach the target (dashed line). Tune the three gains. Try: P only (oscillates), P+D (fast, no overshoot), P+I (eliminates steady-state error), all three (balanced).
A simplified lateral controller for lane keeping:
where $\delta$ is the steering angle and $e_{\text{lateral}}$ is the distance from lane center. Camera detects lane lines → computes error → PID computes steering → car turns → new camera image → repeat at 30 Hz. Modern AVs use MPC (Model Predictive Control), which is PID's sophisticated cousin, but the feedback loop concept is identical.
Every sensor lies. GPS gives a position, but it's off by a few metres. An accelerometer reads $9.81\,\text{m/s}^2$, but the true value might be $9.79$. Statistics quantifies this uncertainty and tells you how much to trust each measurement.
Probability = "how likely is this?" A number between 0 (impossible) and 1 (certain).
Fair coin: $P(\text{heads}) = 1/2$. Fair die: $P(\text{six}) = 1/6$.
Key rules:
arr.reduce((a,b) => a+b) / arr.length)Worked example: GPS readings (metres): 10.2, 9.8, 10.5, 10.1, 9.4
Most sensor errors follow a bell curve — small errors are common, large errors are rare.
The entire shape is defined by just two numbers: $\mu$ (center) and $\sigma$ (width). This is why Gaussians dominate engineering — two parameters describe an entire noise profile.
Adjust $\mu$ and $\sigma$. The shaded bands show 1σ, 2σ, 3σ intervals.
A GPS module spec says "CEP 2.5 m". CEP (Circular Error Probable) = 50% of fixes within this radius. Assuming Gaussian errors:
So 68% of fixes are within 2.12 m, 95% within 4.24 m. An autonomous vehicle using this GPS can't know its position better than ~2 m from GPS alone. That's why you fuse it with camera, LiDAR, wheel odometry, and maps — each has different $\sigma$ values, and the Kalman filter combines them optimally.
You have two sources of information about where a car is:
Neither is perfect. The Kalman filter answers: "What is the best estimate given both?"
If the model says 100 m and the GPS says 103 m, where are you really? It depends on which you trust more:
"Based on physics (the state-space model), where should I be now?"
$$P_{k|k-1} = AP_{k-1}A^T + Q$$"My uncertainty grew because the model isn't perfect ($Q$ = process noise covariance)."
$K$ = Kalman gain. If sensor is precise ($R$ small), $K \to 1$ (trust sensor). If model is precise ($P$ small), $K \to 0$ (trust model).
$$\hat{x}_k = \hat{x}_{k|k-1} + K_k\underbrace{(z_k - H\hat{x}_{k|k-1})}_{\text{innovation (surprise)}}$$"New estimate = prediction + gain × (measurement − predicted measurement)."
$$P_k = (I - K_kH)P_{k|k-1}$$"Uncertainty shrinks because we incorporated new information."
Predict → Measure → Compute Gain → Correct → Repeat forever
A car moves at constant velocity. GPS (red dots) is noisy. The Kalman filter (green) fuses the motion model with measurements. Adjust noise levels — when Q is high, filter trusts GPS more; when R is high, it trusts the model more.
A self-driving car runs an Extended Kalman Filter at 100 Hz:
In a tunnel (no GPS), the filter prediction uncertainty grows and grows. When GPS returns, the first fix causes a large correction (high Kalman gain × big innovation). This predict-update loop — DEs + statistics + linear algebra + numerical methods — runs in every vehicle, drone, phone, and satellite navigation system in the world.
Algebra (language) → Functions (input/output) → Limits (approaching) → Exp/Log (growth/decay) → Derivatives (rates) → Integrals (accumulation) → DEs (rules of change) → Systems (multi-variable) → Numerical (computers solve) → Control (feedback) → Statistics (uncertainty) → Kalman (fuse everything)
Every topic feeds the next. The math isn't abstract — it's the literal code running inside every GPS receiver, every autonomous vehicle, every drone, every ML training loop. You now have the complete foundation.
Source: Comprehensive engineering math curriculum. See also: Trigonometry guide and Linear Algebra guide in this series.