That's the Travelling Salesman Problem (TSP). And the brutal truth? Nobody has found a perfect, fast solution for large inputs. It belongs to a class of problems that gets exponentially harder as you add more cities. For 10 cities there are over 3 million possible routes. For 30? Don't even try to count.

So for my add-on project in the Data Science with R Programming course, I decided to tackle it the way nature does — imperfectly, iteratively, but surprisingly well.

Why Genetic Algorithms?

The honest answer: I was looking for something that felt smart without requiring me to brute-force my way through millions of possibilities.

Genetic Algorithms (GAs) are a family of optimization techniques inspired by biological evolution. The basic idea is that you start with a population of random solutions, evaluate how good each one is, and keep breeding the better ones together — occasionally throwing in a mutation — until the population collectively gets smarter. It's survival of the fittest, applied to route planning.

For TSP specifically, GAs made a lot of sense. There's no closed-form equation to optimize. The search space is combinatorial and chaotic. A GA doesn't need to know why a route is good — it just needs to measure how good it is, and work from there.

Doing This in R — A New Language for Me

I'd been using Python for most of my data science work, so picking up R for this project was a deliberate challenge. R has a reputation for statistics and data analysis, not algorithm implementation. But working through this in R taught me that it's actually quite capable for custom algorithmic work — you just think about it differently.

The vector operations are intuitive once you stop fighting them. sample(), which(), seq_along() — these become second nature quickly. Writing the mutation step (randomly swapping two cities in a route) felt clean and readable in R in a way I didn't expect.

I also ran everything on Google Colab, which handled the R kernel without any setup headaches.

How the Algorithm Works

Here's a breakdown of what I actually implemented, step by step:

1. Initialization

A population of random routes is generated. Each route is just a permutation of all the city indices — a possible order to visit them.

2. Distance Calculation

For each route, I calculate the total Euclidean distance between consecutive cities. This is the core metric everything else depends on.

3. Fitness Evaluation

Fitness is defined as:

Fitness = 1 / (1 + Distance)

Shorter routes get higher fitness. Simple, but effective.

4. Tournament Selection

To pick parents for the next generation, I randomly pull three individuals from the population and take the best one. Run this twice, and you have two parents. This method avoids always picking the same top performers, which keeps diversity in the gene pool.

5. Crossover

A contiguous segment from Parent 1 is copied into the child. The remaining cities are filled in from Parent 2, in order, skipping any that are already present. This preserves valid permutations — no city gets visited twice.

6. Mutation

With a small probability, two cities in a route get swapped. This is what keeps the algorithm from getting stuck in a local optimum. A tiny nudge that occasionally opens up a better path.

7. Elitism

The single best solution from the current generation is always carried forward, unchanged. This ensures the algorithm never loses its best answer while exploring new ones.

Repeat steps 3–7 for hundreds of generations, and the population gradually converges on a near-optimal route.

Results

I tested with two problem sizes:

10 cities: The algorithm converged fast. Best distance landed around 325.93. You could watch the fitness jump in the early generations and then plateau — the classic convergence curve.

30 cities: Harder, slower, but still effective. Best distance reached approximately 565.77. Convergence took longer, and the average population distance kept improving even when the best route had stabilised.

A few things I noticed in the results that I found genuinely interesting:

• The early generations improve fast. The random initial population is so bad that almost any crossover makes things better.

• Mutation occasionally causes a sharp, sudden drop in best distance — a lucky swap that opens up a better sub-path.

• Larger city counts don't just slow things down linearly. You really feel the combinatorial explosion.

What I Actually Learned

Beyond the algorithm itself, a few things stuck with me from this project:

Fitness functions matter more than you'd think. Choosing 1 / (1 + distance) instead of just 1 / distance avoids division-by-zero weirdness and keeps the values in a range that's easy to work with. A small design decision, but it matters.

Elitism is underrated. I initially ran the algorithm without it and watched good solutions disappear between generations. Adding elitism — just carrying forward the single best individual — made convergence visibly more stable.

R is more versatile than its reputation suggests. I went in expecting to miss Python's libraries. I came out respecting R's expressiveness for this kind of work. It's not the language I'd reach for first for systems-level code, but for algorithmic experimentation with data? It holds up.

Near-optimal is often good enough. This is maybe the most practically useful idea from the whole project. TSP is unsolvable "perfectly" at scale, but a solution that's 5% off optimal — found in seconds — is infinitely more useful than an exact answer that takes years to compute. GAs embody that trade-off well.

Where This Stuff Actually Gets Used

TSP isn't just an academic puzzle. The same underlying problem — visit a set of locations in the best order — shows up constantly:

• Delivery route planning (think last-mile logistics)

• Manufacturing: optimising the order in which a robot arm visits drill points

• DNA sequencing: some assembly problems are structurally similar to TSP

• Network packet routing

• Robotics path planning

Genetic Algorithms are used across all of these, usually as one layer in a larger optimization stack.

Final Thoughts

I came into this project thinking "genetic algorithm" sounded more complicated than it was. In practice, the core ideas are accessible: start random, select the good stuff, mix it together, occasionally shake things up. It's the implementation details — crossover strategies, mutation rates, population sizing — where it gets interesting.

Running this in R pushed me to think carefully about the code rather than reach for a pre-built library. That friction was useful. I understood what I built.

If you want to poke around the actual code, it's here: Google Colab Notebook →

Built as part of a Data Science with R Programming course project. First time writing a genetic algorithm from scratch.