Login
Programming Math for Vibe Coders.
Programming Math for Vibe Coders MojoΒ Edition
Introduction
Leslie Lamport has long argued that programming is not simplyΒ coding.
Before writing code, we first need to think precisely about what the program should do and how it shouldΒ behave.
That distinction matters even more in the age of AI-assisted programming.
A coding agent can generate Mojo, Python, Rust, Solidity, JavaScript, or almost any other language inΒ seconds.
But it still needs a precise description of the problem it shouldΒ solve.
This is where mathematics becomes incredibly useful.
Mathematics gives us a compact language for expressing relationships, constraints, quantities, state, and behaviour without committing ourselves to a particular programming language.
For many learnersβββand yes, vibe coders, Iβm calling you out hereβββthe difficult part isnβt necessarily understanding code.
Itβs learning how to moveΒ between:
Idea β Mathematical Model β Algorithm βΒ Code
In this article, weβll explore that process using Mojo π₯, a statically typed systems programming language with Python-like syntax.
The mathematical ideas themselves are independent ofΒ Mojo.
You can translate them into almost any programming language.
That is one of the beautiful things about approaching software mathematically:
The model survives even when the implementation languageΒ changes.
Knowledge TransferΒ Guide
Translating Math to Mojo: CheatΒ Sheet
Summation
β β accumulation using a loop andΒ +=
Product
β β repeated multiplication using a loop andΒ *=
Mathematical bounds
i = 1Β β¦ n β range(1, n +Β 1)
Indexed values
xα΅’ β values[i]
Functions
f(x) β def f(x: Type) ->Β Type:
Real numbers
β βΒ Float64
Integers
β€ βΒ Int
Sequences
xβ, xβ,Β β¦, xβ βΒ List[T]
Infinite sums
β β approximate using a finite number ofΒ terms
One important detail:
Mathematical ranges are commonly inclusive.
For example:
1 β€ k β€Β n
In Mojo, range() follows Python-style half-open ranges.
So:
range(1, n + 1)
represents:
1, 2, 3,Β β¦,Β n
This small difference is exactly the kind of bug mathematical thinking can help usΒ catch.
Factorial: From β to aΒ Loop
Mathematical Definition
n! = β from k = 1 to n ofΒ k
In expandedΒ form:
n! = 1 Γ 2 Γ 3 ΓΒ β¦ ΓΒ n
Mojo Implementation
def factorial(n: Int) raises -> Int:
if n < 0:
raise Error("Factorial is not defined for negative numbers.")
var result: Int = 1
for k in range(1, n + 1):
result *= k
return result
Explanation
The mathematical expression:
β from k = 1 to n ofΒ k
contains three pieces of information.
The variable:
k
becomes our loop variable.
The bounds:
1 β€ k β€Β n
become:
range(1, n + 1)
And theΒ product:
β
becomes:
result *= k
Something subtle is also happening here.
We initialise:
var result: Int = 1
Why 1?
Because 1 is the identity element for multiplication:
1 Γ x =Β x
For addition, the identity element isΒ 0:
0 + x =Β x
So a summation accumulator normally starts atΒ 0.
For multiplication:
1 Γ x =Β x
So a product accumulator starts atΒ 1.
Our implementation also correctly handles:
0! =Β 1
When n = 0, the loop executes zero times and result remainsΒ 1.
This gives us a useful programming principle:
The initial value of an accumulator often comes directly from the mathematics of the operation.
A Mojo-Specific Observation
Unlike Python integers, Mojoβs standard Int integers represent a finite machineΒ integer.
That means sufficiently large factorials will eventually exceed what the type can represent.
The mathematics hasnβtΒ changed.
The representation has.
This gives us another important rule:
Mathematical correctness and representation correctness are not always the sameΒ thing.
Approximating e Using an InfiniteΒ Series
Mathematical Definition
Eulerβs number can be definedΒ as:
e = β from n = 0 to β of 1 /Β n!
Expanded:
e = 1 + 1 + 1/2! + 1/3! + 1/4! +Β β¦
A computer cannot normally execute an infinite number of operations.
So instead we calculate a finite approximation:
e β β from n = 0 to N β 1 of 1 /Β n!
Mojo Implementation
def approximate_e(terms: Int = 12) raises -> Float64:
if terms < 1:
raise Error("terms must be at least 1")
var total: Float64 = 1.0
var term: Float64 = 1.0
for n in range(1, terms):
term /= Float64(n)
total += term
return total
Explanation
We could calculate every factorial independently.
But the mathematics gives us a better algorithm.
We know:
n! = n Γ (n βΒ 1)!
Therefore:
1 / n! = (1 / n) Γ (1 / (n βΒ 1)!)
This means you can calculate each new term from the previousΒ one.
Instead of repeatedly calculating:
1!, 2!, 3!, 4!,Β β¦
we simplyΒ write:
term /= Float64(n)
Then accumulate it:
total += term
This is an important lesson:
Mathematics does not merely describe the answer. It can reveal a better algorithm.
Calculating anΒ Average
Mathematical Definition
For values:
xβ, xβ,Β β¦,Β xβ
the arithmetic meanΒ is:
xΜ = (1 / n) Γ β from i = 1 to n ofΒ xα΅’
In plain language:
average = sum of all values/number ofΒ values
Mojo Implementation
def average(values: List[Float64]) raises -> Float64:
if len(values) == 0:
raise Error("Average is undefined for an empty collection.")
var total: Float64 = 0.0
for i in range(len(values)):
total += values[i]
return total / Float64(len(values))
Explanation
The mathematical summation:
β xα΅’
becomes an accumulator:
var total: Float64 = 0.0
followed by:
for i in range(len(values)):
total += values[i]
Then:
1 /Β n
becomes:
total / Float64(len(values))
Notice the explicit conversion:
Float64(len(values))
len(values) gives us anΒ integer.
Our calculation produces a floating-point result.
The code therefore states the numerical representation explicitly.
This is one place where Mojoβs type system makes mathematical intent moreΒ visible.
The Empty Collection Problem
Suppose:
n =Β 0
Our formula would require division byΒ zero.
So the average of an empty collection is undefined.
This would therefore be misleading:
if len(values) == 0:
return 0.0
Zero is not the average of an empty collection.
There simply is noΒ average.
So instead weΒ use:
raise Error("Average is undefined for an empty collection.")Another useful ruleΒ follows:
Edge cases should follow the mathematical definition, not whatever value is convenient for the implementation.
Computing Variance
Variance measures how far values tend to spread from theirΒ mean.
First calculate theΒ mean:
ΞΌ = (1 / n) Γ β from i = 1 to n ofΒ xα΅’
Then calculate the population variance:
ΟΒ² = (1 / n) Γ β from i = 1 to n of (xα΅’ βΒ ΞΌ)Β²
Mojo Implementation
def variance(values: List[Float64]) raises -> Float64:
if len(values) == 0:
raise Error("Variance is undefined for an empty collection.")
var total: Float64 = 0.0
for i in range(len(values)):
total += values[i]
var mean = total / Float64(len(values))
var squared_difference_sum: Float64 = 0.0
for i in range(len(values)):
var difference = values[i] - mean
squared_difference_sum += difference * difference
return squared_difference_sum / Float64(len(values))
Translating theΒ Equation
Take thisΒ part:
(xα΅’ βΒ ΞΌ)Β²
The currentΒ value:
xα΅’
becomes:
values[i]
Subtract theΒ mean:
xα΅’ βΒ ΞΌ
becomes:
var difference = values[i] - mean
Square the difference:
(xα΅’ βΒ ΞΌ)Β²
becomes:
difference * difference
The summation:
β (xα΅’ βΒ ΞΌ)Β²
becomes:
squared_difference_sum += difference * difference
And finally divide byΒ n:
squared_difference_sum / Float64(len(values))
Population Variance vs SampleΒ Variance
Small mathematical differences matter.
Population varianceΒ uses:
ΟΒ² = (1 / n) Γ β(xα΅’ βΒ ΞΌ)Β²
Sample variance usuallyΒ uses:
sΒ² = (1 / (n β 1)) Γ β(xα΅’ βΒ xΜ)Β²
The implementation difference may appearΒ tiny.
Population:
Float64(len(values))
Sample:
Float64(len(values) - 1)
But mathematically these represent different quantities.
This is exactly why specification matters.
A coding agentΒ told:
Calculate variance.
has to make assumptions.
A coding agentΒ given:
ΟΒ² = (1 / n) Γ β(xα΅’ βΒ ΞΌ)Β²
has much less room toΒ guess.
The BiggerΒ Lesson
At first these examples may lookΒ simple.
β becomes multiplication inside aΒ loop.
β becomes accumulation.
xα΅’ becomes an indexedΒ value.
f(x) becomes a function.
But a more important idea underlies all ofΒ this.
We are learning to move through fourΒ layers:
Problem β Mathematical Model β Algorithm βΒ Code
Most vibe coding jumps directlyΒ from:
Problem β AI-Generated Code
That works surprisingly often.
Until itΒ doesnβt.
The problem is ambiguity.
Natural language mightΒ say:
Execute when everyoneΒ agrees.
We can express that more precisely.
Let:
P = {pβ, pβ,Β β¦,Β pβ}
represent all participants.
Let:
A βΒ P
represent the participants who have accepted.
Then we canΒ define:
Ready(I) β A =Β P
In plain language:
The intent is ready exactly when the set of accepting participants equals the set of required participants.
Now addΒ time:
Ready(I) β A = P AND t < expiry(I)
Now we have expressed two requirements:
- Everyone mustΒ accept.
- The intent must not haveΒ expired.
An AI coding agent can translate that into Mojo, Solidity, Rust, Python, TypeScript, or another language.
The implementation language canΒ change.
The specification remains.
From Vibe Coding to Specification
This suggests a different way of thinking about AI-assisted software development.
Instead of:
Natural Language β Generated Code
we canΒ use:
Natural Language β Mathematical Intent β Specification β Generated Code βΒ Tests
The goal isnβt necessarily for every programmer to become a mathematician.
The goal is to understand enough mathematical language to describe software behaviour precisely.
Because the future skill may not be memorising every programming languageβs syntax.
It may be something more fundamental:
Learning to express intent precisely enough that humans, machines, and proofs agree on what the program is supposed toΒ do.
Programming Math for Vibe Coders. was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.
