The goal of this first post is to establish a foundation that’s:

• easy to run,

• easy to debug,

• and easy to evolve without regret.

So today we’ll do exactly one thing: ship a minimal server with a /health endpoint, and make sure it logs requests in a way that won’t annoy future me.

The “why”

S3 emulation sounds straightforward until you try to make it compatible with real tooling (AWS SDKs, AWS CLI), and then you realize the API surface is huge and full of edge cases. So instead of building “all of S3”, I’m building a small scoped emulator that’s great for local development and CI, and I’m writing down decisions as I go.

Project setup (workspace + server)

Right now the workspace has two crates:

• awrust-s3-domain — domain logic (empty for now)

• awrust-s3-server — the HTTP server

At this stage, the server listens on 0.0.0.0:4566 and serves a single endpoint:

• GET /health → {"status":"ok"}

The code (first vertical slice)

Here’s the entire server for this first step:

use axum::{routing::get, Json, Router};
use serde::Serialize;
use std::net::SocketAddr;
use tower_http::trace::{DefaultMakeSpan, DefaultOnResponse, TraceLayer};
use tracing::{info, Level};
use tracing_subscriber::{fmt, EnvFilter};

#[derive(Serialize)]
struct HealthResponse {
    status: &'static str,
}

#[tokio::main]
async fn main() {
    init_tracing();

    let app = Router::new()
        .route("/health", get(health))
        .layer(
            TraceLayer::new_for_http()
                .make_span_with(DefaultMakeSpan::new().level(Level::INFO))
                .on_response(DefaultOnResponse::new().level(Level::INFO)),
        );

    let addr: SocketAddr = "0.0.0.0:4566".parse().expect("valid listen addr");
    info!(service = "s3", %addr, "awrust-s3 server starting");

    let listener = tokio::net::TcpListener::bind(addr).await.expect("bind listen addr");
    axum::serve(listener, app).await.expect("server error");
}

async fn health() -> Json<HealthResponse> {
    Json(HealthResponse { status: "ok" })
}

fn init_tracing() {
    let filter = EnvFilter::try_from_default_env()
        .unwrap_or_else(|_| EnvFilter::new(Level::INFO.to_string()));

    fmt()
        .json()
        .with_env_filter(filter)
        .with_current_span(true)
        .with_span_list(true)
        .init();
}

Why these dependencies?

For now, I’m keeping the stack boring and well-supported:

• Tokio — the async runtime (most of Rust’s server ecosystem assumes it)

• Axum — minimal HTTP routing on top of Hyper/Tokio

• Tracing + tracing-subscriber — structured logs and request-level context

• tower-http TraceLayer — request logging (method/path/status/latency) with minimal code

I wrote short ADRs documenting these choices, because future changes are easier when “why” is recorded.

“Why wasn’t it logging requests?”

One small gotcha: TraceLayer logs under the tower_http target, and log levels/filters matter.

I set explicit INFO levels for:

• span creation (make_span_with)

• response logging (on_response)

That way, hitting /health reliably prints something like:

{
  "level":"INFO",
  "target":"tower_http::trace::on_response",
  "fields":{"message":"finished processing request","status":200,"latency":"0 ms"},
  "span":{"method":"GET","uri":"/health"}
}

This is important early. Debuggability is part of the product.

Running it

From the server crate:

cargo run

Then:

curl -s localhost:4566/health; echo

To adjust log levels:

RUST_LOG=info cargo run

or to go noisier:

RUST_LOG=debug cargo run

What’s next (Part 2)

Now that the server is alive and observable, the next step is the first real “S3-shaped” feature:

• a Store trait

• a MemoryStore

• and the first endpoints:

  • PUT /<bucket>

  • PUT /<bucket>/<key>

  • GET /<bucket>/<key>

Once those work, I’ll validate the contract using AWS CLI.

It looked like a colony sim:

• pawns moved

• trees got chopped

• numbers went up

• UI reacted

But under the hood, it was cheating.

There was only one pawn really doing work.

This post is about what happened when I stopped cheating.

From one pawn to many

The first lie was obvious: if pawn.id == 0 { ... }

That single check kept everything simple:

• one job at a time

• no conflicts

• no coordination problems

Removing it was the first real step toward a simulation instead of a scripted demo.

Once I removed the early break in tick_jobs, every pawn started ticking… and immediately exposed a new class of problems.

That was expected. And, honestly, kind of satisfying.

The “everyone go chop the same tree” problem

As soon as multiple pawns existed, they all did the same thing:

• find the nearest tree

• walk to it

• start chopping

Which, of course, meant they all picked the same tree.

This is the moment where you realize: Pawns are not smart. They need to be coordinated

So I introduced a tiny but powerful concept: reservations.

Reservations: the smallest coordination system that works

I added a Reservations resource that tracks which world tiles are already claimed.

The rules are straightforward

• idle pawns reserve a tree before walking to it

• reserved trees are skipped by other pawns

• reservations are released when:

  • chopping finishes

  • the tree disappears

  • the task aborts

Resource:

#[derive(Resource)]
pub struct Reservations {
    pub reserved_tiles: HashMap<IVec2, Entity>
}

Claim on idle:

if let Some(tree) = find_nearest_tree(map, from, reservations) {
    reservations.reserved_tiles.insert(tree, pawn_entity);
    Task::GoToTree(tree)
} else {
    Task::Idle
}

Release when done / invalid:

let next = progress + 1;
if next >= 10 {
    world::set_with_sprite(map, &tile_entities, q_tiles, at.x, at.y, Tile::Ground);
    inv.wood += 1;
    if reservations.reserved_tiles.get(&at) == Some(&pawn_entity) {
        reservations.reserved_tiles.remove(&at);
    }
    Task::GoToStockpile
} else {
    Task::Chop { at, progress: next }
}

No locks. No queues. No AI magic.
Just a set of intents.

And suddenly:

• pawns spread out naturally

• no more dogpiling

• task lifecycles became clearer

Selection is not pawn 0

Another quiet lie in the earlier version:
the UI always showed pawn id == 0.

That’s fine, until you have more than one pawn.

So I added a SelectedPawn resource and some very basic click-to-select logic:

• click a pawn → it becomes selected

• selected pawn gets a visual highlight

• the inspector UI shows that pawn’s state

Nothing fancy, but suddenly the simulation feels interactive instead of hardcoded.

“What if I spawn 1000 pawns?”

This was the fun (and dangerous) thought.

I cranked PAWN_COUNT up to 1000 and immediately learned why most games don’t do this casually.

Spawning pawns with fixed offsets doesn’t scale, so I switched to:

• a spiral search around the stockpile

• skipping trees and occupied tiles

• validating positions against the world map

This required reordering world initialization so pawn spawning could query the map instead of guessing.

for p in spiral_positions(stockpile, max_radius) {
    if spawned >= PAWN_COUNT { break; }
    if p.x < 0 || p.x >= MAP_W || p.y < 0 || p.y >= MAP_H { continue; }
    if world::get(map, p.x, p.y) == Tile::Tree { continue; }
    if occupied.contains(&p) { continue; }
    occupied.insert(p);

    commands.spawn((Pawn { id: spawned as u32, x: p.x, y: p.y }, /* sprite */, /* task */));
    spawned += 1;
}

The result:

• pawns spawn cleanly

• no overlaps

• no trees overwritten

• no hardcoded magic numbers

The beautiful lag

Then came the best part.

With 1000 pawns and a large forest, everything ran fine…
until trees started getting sparse.

Frame time exploded.

Why?

Because every pawn was scanning the entire map to find the nearest tree.

That’s when the illusion fully shattered. I added a FPS indicator to illustrate the problem.

WorldTrees: stop scanning the universe

The fix was simple and very unglamorous:

• maintain a WorldTrees index (HashSet<IVec2>)

• iterate only existing trees

• remove trees from the index when chopped

Index:

#[derive(Resource)]
pub struct WorldTrees(pub HashSet<IVec2>);

Iterate only trees instead of the full grid:

for &target in world_trees.0.iter() {
    let reserved = reservations.reserved_tiles.contains_key(&target);
    if !reserved && world::get(map, target.x, target.y) == Tile::Tree {
        let dist = (from.x - target.x).abs() + (from.y - target.y).abs();
        // keep best...
    }
}

Remove when chopped:

world_trees.0.remove(&at);

Suddenly:

• late-game performance stabilized

• search cost scaled with remaining trees, not map size

• the simulation stopped punishing success

What’s next

At this point:

• multiple pawns work concurrently

• jobs are coordinated

• selection and inspection are real

• performance problems are visible and explainable

There’s still a lot that could be done here: collisions, better pathfinding, smarter work distribution.

But for now, I’m pretty happy watching 1000 tiny idiots politely avoid chopping the same tree.

The code at this stage is available on GitHub under the post-4 tag: https://github.com/GuzzoLM/tiny-colony/tree/post-4/tiny-colony

Everything compiled. Things moved.
And… that was about it.

At that point, pawns were basically well-behaved pixels. They could move, but they didn’t really do anything. There was no intent, no persistence, no reason for a pawn to go somewhere other than because I told it to.

This post is about fixing that.

The real problem: movement is not behavior

Initially, I had a system that moved pawn 0 toward a hardcoded target. It worked fine, but it immediately felt wrong:

• It didn’t scale beyond one pawn

• The logic was brittle

• Nothing was inspectable or debuggable

• There was no concept of why a pawn was moving

In other words:
I was telling pawns how to move, not what they were trying to achieve.

So I stopped doing that.

Tasks: making pawn intent explicit

The first big shift was introducing a Task component.

Instead of directly moving pawns, each pawn now carries an explicit job state. In simplified form, it looks like this:

#[derive(Component, Debug)]
pub enum Task {
    Idle,
    GoToTree(IVec2),
    Chop { at: IVec2, progress: f32 },
    GoToStockpile,
}

This enum does a lot of heavy lifting.

Instead of “a system that moves pawns”, the simulation now has pawns with intent. A pawn isn’t being pushed around, it’s in a state, and systems simply react to that state.

This has a few immediate benefits:

• Behavior becomes inspectable

• Refactors stop breaking everything

• UI becomes trivial later

At this point, pawns finally stopped being dots and started being… workers.

A quick aside: why tasks feel so nice in Rust

One thing I really liked here is how naturally tasks with different data fit into the model.

In Rust, enums aren’t just labels. Each variant can carry its own data:

pub enum Task {
    Idle,
    GoToTree(IVec2),
    Chop { at: IVec2, progress: f32 },
    GoToStockpile,
}

Each task only carries exactly what it needs. No optional fields, no “only valid when state == X” comments.

This isn’t completely unique to Rust, but Rust makes it unusually pleasant and safe. In C# or Java this often turns into class hierarchies or nullable fields; in Python it’s easy to represent, but easy to misuse.

Here, the type system does most of the work: adding a new task forces you to handle it everywhere, and impossible states simply can’t exist.

For a simulation where behavior is state, that turned out to be a really good fit.

The world grows up: introducing WorldMap

Once pawns had tasks, they needed to reason about the world:

• Is there still a tree at this position?

• Did another pawn already chop it?

• What happens to the tile when the tree is gone?

To support this, I introduced a WorldMap resource. It owns:

• The tile grid

• Tile types (Ground, Tree, Stockpile)

• Small helpers to query and mutate tiles

The important design choice here is ownership:

Pawns don’t own the world.
They query it, reason about it, and sometimes modify it — but the world is shared state.

This cleared up a lot of accidental coupling early on and made the simulation logic much easier to reason about.

Colony state: stockpiling without pawns knowing

Next question: where does the chopped wood go?

Instead of letting pawns “own” resources, I added a Colony resource:

#[derive(Resource, Default)]
pub struct Colony {
    pub wood: u32,
}

Pawns don’t know how much wood the colony has.
They just deliver items into it.

This separation turned out to be surprisingly nice:

• Pawns stay simple

• Colony-wide logic stays centralized

• UI and future systems have a clean place to read from

It also mirrors how I want the game to feel later: pawns do work, the colony accumulates results.

The job loop

At this point, the simulation loop stopped being about movement and became about progression.

Very roughly, a pawn now follows this loop:

Idle
 → GoToTree
 → Chop (with progress)
 → GoToStockpile
 → DropOff
 → Idle

No single system “knows” this whole flow.

Each task handler only knows:

• What it needs to do right now

• When it’s done

• What the next task should be

For example, chopping a tree looks roughly like this:

pub fn handle_chop(
    pawn: &mut Task,
    colony: &mut Colony,
    world: &mut WorldMap,
) {
    if let Task::Chop { at, progress } = pawn {
        *progress += 0.01;

        if *progress >= 1.0 {
            world.set_with_sprite(*at, Tile::Ground);
            colony.wood += 1;
            *pawn = Task::GoToStockpile;
        }
    }
}

No scheduler.
No behavior tree.
Just “are we done yet?” — and if so, move on.

And yes, watching the first pawn successfully chop a tree felt way better than it should have.

Observability: adding the first UI

At this point, the simulation worked. But I couldn’t see what was going on inside it.

So I added UI early. Not for gameplay, but for observability.

Two simple UI sections:

Colony UI

• Current wood count

Pawn inspector

• Pawn ID

• Grid position

• Current task

• Task progress (when applicable)

This paid off immediately.

Suddenly I could:

• See task transitions

• Verify progress increments

• Spot logic bugs instantly

The UI isn’t gameplay yet.
It’s a debugging tool that happens to be on screen.

A small detour: change detection

While wiring up the UI, I ran into something new (for me): change detection.

My first version updated the UI every frame. That works, but it’s noisy, both mentally and architecturally.

Bevy lets you filter queries so systems only run when something actually changed:

Query<(&Pawn, &Task), Changed<Task>>

This query only returns pawns whose Task component changed since the last frame. If a pawn is still chopping the same tree, the UI system doesn’t even run for it.

A few clarifications:

• This is not an optimization I needed yet

• It’s mostly about intent: “update UI when state changes”

• Unexpected UI updates now usually mean unexpected state changes

I like this pattern because it nudges the code toward being event-driven, without having to introduce explicit events this early.

Keeping visuals honest: updating tile sprites

One annoying issue showed up quickly:

• A tree would be chopped in the simulation…

• …but visually, it stayed a tree forever

To fix this, I added a simple mapping from logical tiles to sprite entities. Tile updates now go through a centralized helper that updates both:

• The world state

• The corresponding sprite color

Once this was in place, visuals stopped lying.

Small refactors that paid off

As the systems grew, I made a few unglamorous but valuable cleanups:

• Centralized tile + sprite updates

• Used change detection for UI instead of per-frame updates

• Reduced UI marker components into a single enum

• Cleaned up system signatures and warnings

None of these are flashy, but together they made the codebase much calmer to work in.

Where things stand now

At this point, the project has crossed an important threshold.

The simulation now:

• Has intentional pawn behavior

• Modifies shared world state

• Keeps visuals in sync automatically

• Exposes internal state via UI

It’s still tiny.
It’s still very much a toy.

But it’s no longer just rendering things, it’s simulating a system.

In the next steps, I want to explore:

• Multiple pawns competing for work

• Job selection instead of hardcoded flows

• Basic player interaction and selection

For now though, this feels like a good stopping point.

The dots have learned to work. 🙂

The code at this stage is available on GitHub under the post-3 tag: https://github.com/GuzzoLM/tiny-colony/tree/post-3/tiny-colony

This post covers the next step: rendering a grid, spawning pawns, and moving one of them using a fixed simulation tick.

The world is just a grid

At its core, the world is a fixed-size grid:

pub const MAP_W: i32 = 64;
pub const MAP_H: i32 = 64;

Tiles are stored as a flat vector:

#[derive(Clone, Copy)]
enum Tile {
    Ground,
    Tree,
    Stockpile,
}

There’s no map abstraction yet — just a Vec<Tile> and some helpers to translate between grid coordinates and world coordinates.

fn grid_to_world(x: i32, y: i32) -> Vec3 {
    let origin_x = -(MAP_W as f32) * TILE_SIZE * 0.5 + TILE_SIZE * 0.5;
    let origin_y = -(MAP_H as f32) * TILE_SIZE * 0.5 + TILE_SIZE * 0.5;

    Vec3::new(
        origin_x + x as f32 * TILE_SIZE,
        origin_y + y as f32 * TILE_SIZE,
        0.0,
    )
}

This keeps the simulation grid-centered and avoids camera math early on.

Rendering tiles (brute force, yay!)

Each tile is rendered as a simple sprite, tinted by type:

commands.spawn((
    Sprite {
        color,
        custom_size: Some(Vec2::splat(TILE_SIZE - TILE_GAP)),
        ..default()
    },
    Transform::from_translation(world_pos),
));

This means spawning 64 × 64 = 4096 sprites on startup.

Is that optimal? Probably not.
Is it good enough for now? Absolutely.

One of the nice things about Bevy is how easy it is to brute-force something visible without caring about performance too early.

Pawns are data first, visuals second

A pawn is deliberately boring:

#[derive(Component)]
struct Pawn {
    id: u32,
    x: i32,
    y: i32,
}

No animation, no state machine, no behavior tree.

Visually, pawns are just small circles rendered slightly above tiles:

commands.spawn((
    Pawn { id, x, y },
    Sprite {
        image: circle_image.clone(),
        color: Color::srgb(0.85, 0.85, 0.95),
        custom_size: Some(Vec2::splat(TILE_SIZE - 2.0)),
        ..default()
    },
    Transform::from_translation(world_pos + Vec3::Z),
));

The circle texture itself is generated in code, not loaded from disk. This keeps iteration fast and avoids asset management entirely at this stage.

A fixed simulation tick

The most important step so far was introducing a fixed simulation clock.

struct Sim {
    paused: bool,
    speed: f32,
    tick: Timer,
    target: IVec2,
}

This separates:

• simulation time (deterministic)

• rendering time (best effort)

The tick runs at 10 Hz:

Timer::from_seconds(0.10, TimerMode::Repeating)

And can be paused or sped up independently from framerate.

Moving one pawn (dumbest way possible)

With the simulation tick in place, I implemented the simplest possible behavior:

Move pawn id = 0 one grid tile per tick toward a fixed target.

if pawn.x < target.x {
    pawn.x += 1;
} else if pawn.x > target.x {
    pawn.x -= 1;
} else if pawn.y < target.y {
    pawn.y += 1;
} else if pawn.y > target.y {
    pawn.y -= 1;
}

After updating the grid position, the render transform is updated accordingly:

let pos = grid_to_world(pawn.x, pawn.y);
transform.translation = pos + Vec3::Z;

No smoothing, no interpolation, no pathfinding.

But once the pawn started moving, the project immediately felt more “alive”.

Early lessons

A few things became clear very quickly:

• Bevy makes it easy to get something visible fast

• Rust’s borrow checker shows up early, but usually points to real design improvements

• Fixed-tick simulation feels right for this genre

Most importantly: keeping the scope small made it possible to actually finish these steps.

Current state

At this point, Tiny Colony has:

• a grid-based world

• basic terrain

• multiple pawns as ECS entities

• a fixed simulation loop

• pause and speed controls

• one pawn moving deterministically

That’s enough of a foundation to start building actual gameplay.

The code at this stage is available on GitHub under the post-1 tag: https://github.com/GuzzoLM/tiny-colony/tree/post-1/tiny-colony

More than once, actually. A small, fantasy-flavored colony simulation: a few people, a piece of land, some basic production, and the feeling that things slowly start to work on their own. Every time I approached it with decent intentions and familiar tools (Unity, C#, things I use professionally), and every time it quietly died.

The reasons were always the same: lack of time, increasing scope, and no clear stopping point.

This time, I’m trying something different. I want to keep the project small, treat it as a learning exercise, and, most importantly, actually finish something. I’ve also been wanting to learn Rust for a while, mostly out of curiosity. This project is a way to combine both goals.

This is not a commercial game, and it’s not meant to be a polished tutorial series. Think of it more as a public lab notebook: documenting decisions, constraints, and small steps taken along the way.

The “game”

At its core, the game is a very small, RimWorld-inspired colony simulation.

There is a fixed grid world. A handful of pawns live in it. Some tiles contain trees, which can be chopped for wood. There is a stockpile. Pawns autonomously go to trees, chop them, and haul the wood back to the stockpile.

That’s the entire gameplay loop.

There are no grand narratives, no diplomacy systems, no deep needs simulation. Just a simple loop that is easy to reason about and, crucially, easy to finish.

In scope

For the first version, the scope is deliberately constrained to:

• a fixed-size grid map

• around 10 pawns

• trees with a finite amount of wood

• hauling wood to a stockpile

• a fixed tick-based simulation loop

• minimal UI for debug information (wood count, tick rate, pause/speed controls)

Explicitly out of scope

Equally important is what this version will not include:

• hunger, mood, relationships, or social systems

• building placement or construction

• diplomacy, factions, combat, or military mechanics

• advanced pathfinding or optimization

• editor tooling or polished UI

Why Rust

I don’t have a professional reason to use Rust here. This is not about picking the “best” language.

I’ve wanted to learn Rust for a while because it sits at an interesting intersection of systems programming, safety, and performance. Simulation-heavy problems are a natural fit for its strengths, and the language forces a level of clarity that I find appealing.

Using Rust here is mostly about curiosity and learning, trying something new outside my usual stack, in a context where correctness and explicit data flow matter.

Why Bevy

For the engine, I chose Bevy.

Bevy is a Rust-native game engine built around an ECS (Entity-Component-System) architecture. That model maps very naturally to simulation-heavy games, where behavior emerges from many small rules applied over large sets of entities.

I also like Bevy’s code-first workflow. There’s no heavy editor dependency, and most of the logic lives directly in Rust code. That makes it easier to reason about what’s actually happening, and easier to keep the project lightweight.

Bevy isn’t the simplest option, and it’s certainly not the most mature engine available. But it strikes a good balance between control and productivity, and it’s a solid excuse to explore ECS-driven design in practice.

High-level architecture

At a high level, the project follows a few simple principles:

• the game is built using ECS concepts: entities are data, behavior lives in systems

• the simulation runs on a fixed tick rate

• rendering is decoupled from simulation logic

• most game behavior is data-driven rather than object-oriented

There’s no attempt here to design a reusable framework or an extensible engine. This is a small, purpose-built simulation.

Constraints and rules

To avoid repeating past mistakes, I’m imposing a few rules on myself:

• no expanding scope mid-iteration

• one small feature per milestone

• refactor only when something actively hurts

• once a milestone works, stop and write about it

This post explores exact algorithms for solving the Traveling Salesman Problem (TSP), including brute force, dynamic programming (Held-Karp), and branch-and-bound. These methods guarantee the shortest path but come with varying levels of computational expense.

You can find the complete implementations for all algorithms discussed in this series, as well as a simple benchmark tool for running comparisons, in my GitHub repository.

In the world of optimization, finding the exact solution to the Traveling Salesman Problem (TSP) is like discovering the holy grail of route planning. While heuristic and metaheuristic methods can provide approximate solutions quickly, exact algorithms go a step further—they guarantee the shortest possible path, offering unmatched precision.

But precision comes at a cost. Exact algorithms are computationally expensive, especially as the number of cities grows. Despite this, they remain invaluable tools for small to medium-sized problems and for understanding the theoretical underpinnings of TSP.

In this post, we’ll explore three cornerstone exact methods: brute force, dynamic programming (Held-Karp), and branch-and-bound. Each method takes a unique approach to tackle the exponential complexity of TSP, and we’ll break down how they work, where they shine, and their limitations. In the end we will compare them and check when it’s advisable to use each one.

Ready to dive into the world of optimal solutions? Let’s get started!

Brute Force: The Simplest Approach

The brute force method systematically explores all possible routes for the Traveling Salesman Problem (TSP) to guarantee finding the optimal solution. While elegant in its simplicity, it quickly becomes computationally expensive due to factorial growth (O(n-1)!).

To ensure consistency and facilitate comparisons between different algorithms, all solvers in this series implement the same interface:

public interface TspSolver {
    int[] solve(int[][] distanceMatrix);
    String getName();
}

This interface defines two methods:

• solve(int[][] distanceMatrix): Takes a distance matrix as input and returns the optimal route as an array of city indices.

• getName(): Returns the name of the algorithm for easy identification.

By adhering to this interface, each solver can be swapped in and out seamlessly, allowing for straightforward comparisons of performance, accuracy, and computational efficiency.

The brute force method is implemented as follows:

Step 1: Preparing the List of Cities

First, we need a list of cities (indices) to generate all possible routes. The city at index 0 is treated as the starting point, so we exclude it from the list of cities to permute:

var cities = new int[distanceMatrix.length - 1];
for (int i = 1; i < distanceMatrix.length; i++) {
    cities[i - 1] = i;
}

Here:

• distanceMatrix.length is the total number of cities.

• We populate the cities array with indices from 1 to (n−1), as city 0 is fixed as the starting and ending point.

Step 2: Generating All Possible Routes

We use recursion to generate all permutations of the cities. The recursive method getRoutes takes the following parameters:

• cities: The list of city indices to permute.

• visited: A boolean array to track which cities have been included in the current route.

• route: An array to store the current permutation.

• start: The current depth of recursion.

Here’s how the recursive method works:

private List<int[]> getRoutes(int[] cities, boolean[] visited, int[] route, int start) {
    var routes = new ArrayList<int[]>();

    // Base case: if the route is complete, add it to the list
    if (start == cities.length) {
        routes.add(route.clone());
    }

    // Recursive case: add each unvisited city to the route
    for (int i = 0; i < cities.length; i++) {
        if (visited[i]) continue;

        // Mark the city as visited and add it to the route
        route[start] = cities[i];
        visited[i] = true;

        // Recurse to fill the next position in the route
        routes.addAll(getRoutes(cities, visited, route, start + 1));

        // Backtrack: unmark the city and reset the route position
        route[start] = 0;
        visited[i] = false;
    }

    return routes;
}

Step 3: Evaluating Each Route

Once all routes are generated, we use the DistanceCalculator class to evaluate each route and find the shortest one.

public class DistanceCalculator {
    private DistanceCalculator() {}

    public static int calculateTotalDistance(int[] route, int[][] distances) {
        var totalDistance = 0;

        for (int i = 0; i < route.length - 1; i++) {
            var city = route[i];
            var nextCity = route[i + 1];
            totalDistance += distances[city][nextCity];
        }

        return totalDistance;
    }
}

This utility method calculates the total distance for a given route by iterating through the route array and summing the distances between consecutive cities. The final distance is returned.

Here’s how it integrates into the solver.

var bestRoute = new int[cities.length + 2];
var currentRoute = new int[cities.length + 2];
var shortestDistance = Integer.MAX_VALUE;

for (var route : routes) {
    // Insert the start and end points (city 0)
    System.arraycopy(route, 0, currentRoute, 1, cities.length);

    // Calculate the total distance of the route
    var routeDistance = DistanceCalculator.calculateTotalDistance(currentRoute, distanceMatrix);

    // Update the shortest distance and best route if necessary
    if (routeDistance < shortestDistance) {
        shortestDistance = routeDistance;
        bestRoute = currentRoute.clone();
    }
}

Example Walkthrough

Suppose we have 4 cities with the following distance matrix:

1. The recursive method generates all possible routes:

   • [B, C, D], [B, D, C], [C, B, D], etc.

2. Each route is evaluated by inserting city A (0) at the start and end:

   • A → B → C → D → A = 10 + 35 + 30 + 20 = 95.

3. The shortest route and its distance are returned.

Strengths and Limitations

Strengths:

• Guarantees the shortest route (optimal solution).

• Straightforward to understand and implement.

Limitations:

• Computationally expensive (O(n-1)!).

• Becomes infeasible for larger datasets.

Dynamic Programming: The Held-Karp Algorithm

Dynamic programming is a powerful technique for solving optimization problems by breaking them down into smaller, overlapping subproblems. Instead of solving each subproblem repeatedly, results are stored and reused, significantly reducing redundant computations.

The Held-Karp algorithm applies this principle to the Traveling Salesman Problem (TSP), offering a more efficient alternative to brute force. Although it still has exponential time complexity (O(n²⋅2^n)), it’s far better than the factorial growth of brute force (O(n!)).

The algorithm uses a dynamic programming table to store the shortest paths. Here's how it works:

Define Subproblems:
Let dp[S][i] represent the shortest path to visit all cities in the subset S, ending at city i.

• S: A subset of cities (excluding the starting city).

• i: The last city in the path.

Base Case:
For the starting city (city 0):

$$dp[\{0\}][0]=0$$

This means the cost to start at city 0 is 0.

Recursive Relation:
For each subset S containing city i, calculate:

$$dp[S][i] = \min_{j \in S, j \neq i} \left( dp[S \setminus \{i\}][j] + \text{dist}[j][i] \right)$$

This means the shortest path to i is the minimum cost of visiting a city j in subset S (excluding i), plus the cost of traveling from j to i.

Final Step:
After filling the table, calculate the shortest path that returns to the starting city:

$$\text{cost} = \min_{i \neq 0} \left( dp[\{1, 2, \dots, n-1\}][i] + \text{dist}[i][0] \right)$$

Example Walkthrough

Suppose we have the same scenario from the example solved with Brute Force.

Step 1: Initialization

We start by defining the dynamic programming table dp[S][i]

Initially:

$$dp[\{0\}][0]=0$$

This means the cost of starting at city A (city 0) is 0.

All other entries in the table are initialized to infinity (∞), as they represent uncomputed or invalid states.

Step 2: Building the Table

We compute the values of dp[S][i] iteratively for all subsets S of increasing size. Let’s break it down:

Subset S={0,1} ending at B (city 1):

$$dp[\{0,1\}][1]=dp[\{0\}][0] + dist[0][1]$$

Substituting values:

$$dp[\{0,1\}][1]=0+10=10$$

Subset S={0,2} ending at C (city 2):

$$dp[\{0,2\}][2]=dp[\{0\}][0] + dist[0][2]$$

Substituting values:

$$dp[\{0,2\}][2]=0 + 15=15$$

Subset S={0,3} ending at D (city 3):

$$dp[\{0,3\}][3] = dp[\{0\}][0]+dist[0][3]$$

Substituting values:

$$dp[\{0,3\}][3] = 0 + 20=20$$

Step 3: Expanding Subsets

We now compute for larger subsets, such as S={0,1,2} and S = {0,1,2,3}.

Subset S={0,1,2} ending at C (city 2):

$$dp[\{0,1,2\}][2]=min(dp[\{0,1\}][1]+dist[1][2])$$

Substituting values:

$$dp[\{0,1,2\}][2] = min(10 + 35) = 45$$

Applying to the all subsets of this same size, we have:

• dp[{0,1,2}][1]=50

• dp[{0,1,2}][2]=45

• dp[{0,1,3}][1]=45

• dp[{0,1,3}][3]=35

• dp[{0,2,3}][2]=50

• dp[{0,2,3}][3]=45

Subset S={0,1,2,3} ending at D (city 3):

$$dp[\{0,1,2,3\}][3]=min(dp[\{0,1,2\}][1]+dist[1][3],dp[\{0,1,2\}][2]+dist[2][3])$$

Substituting values:

$$dp[\{0,1,2,3\}][3]=min(50+35,45+30)=min(85,75)=75$$

Applying to the all subsets of this same size, we have:

• dp[{0,1,2,3}][1]=70

• dp[{0,1,2,3}][2]=65

• dp[{0,1,2,3}][3]=75

Step 4: Final Step

After filling all entries in the table, compute the minimum cost of completing the cycle

$$\text{cost} = \min_{i \neq 0} \left( dp[\{0,1,2,3\}][i] + \text{dist}[i][0] \right)$$

Substituting values:

$$\text{cost} = \min_{i \neq 0} \left( dp[\{0,1,2,3\}][1] + \text{dist}[1][0],\{0,1,2,3\}][2] + \text{dist}[2][0],\{0,1,2,3\}][3] + \text{dist}[3][0] \right)$$

$$\text{cost} = \min_{i \neq 0} \left( 70 + 10, 65+15, 75+20 \right)=min(80,80,95)=80$$

Step 5: Reconstruct the shortest route:

The minimum cost is 80 and it occurs when the route ends either at B (city 1) or C (city 2). Reconstructing the route back from the dynamic programming table, we have the two optimal routes.

• A → C → D→ B → A

• A → B → D → C → A

Implementation

Now that we know how this method works, let’s begin implementing our new solver. We’ll start by initializing the needed variables.

var n = distanceMatrix.length; // Number of cities
var dp = new int[1 << n][n]; // The dynamic programming table
var parent = new int[1 << n][n]; // Stores the optimal end city from previous subsets

You might have noticed we initialized the matrix with size 1 << n. For those not familiarized, 1 << n is a bitwise operation that computes 2^n, representing the total number of subsets of n cities. Here’s how it works:

• Bitmasking: We use an integer's binary representation to encode subsets of cities. Each bit in the integer corresponds to whether a particular city is included in the subset:

  • Bit 0: Represents city 0 (A).

  • Bit 1: Represents city 1 (B).

  • Bit 2: Represents city 2 (C), and so on.

• Example for n=4:

  • 1<<4=16, meaning there are 2^4 = 16 subsets of cities.

  • Each subset is represented by a binary number:

    • 0001: Subset {0}, only city A.

    • 0101: Subset {0,2}, cities A and C.

    • 1111: Subset {0,1,2,3}, all cities.

Bitmasking uses bitwise operations to efficiently manipulate and check subsets:

1. Checking if a City is in the Subset:

   • mask & (1 << city) checks whether the bit corresponding to city is set to 1 in mask.

   • Example: If mask = 5 (0101):

     • mask & (1 << 2) → 0101 & 0100 = 0100 ≠ 0, so city 2 is in the subset.

     • mask & (1 << 1) → 0101 & 0010 = 0000 = 0, so city 1 is not in the subset.

2. Adding a City to the Subset:

   • mask | (1 << city) sets the bit corresponding to city to 1.

   • Example: Add city 1 to mask = 5 (0101):

     • 0101 | 0010 = 0111, so the new subset is {0,1,2}.

3. Removing a City from the Subset:

   • mask ^ (1 << city) toggles the bit corresponding to city.

   • Example: Remove city 2 from mask = 5 (0101):

     • 0101 ^ 0100 = 0001, so the new subset is {0}.

Using bitmasking for representing the subsets gives us efficiency (check, add and remove lements is O(1)) and a compact representation, requiring only O(n) bits for each subset.

Back to our implementation, now we initialize our DP table, setting all entries to infinity. This ensures that only valid transitions update the table. If a state is never computed, it remains at infinity.

for (var i = 0; i < (1 << n); i++) {
    Arrays.fill(dp[i], Integer.MAX_VALUE);
}

dp[1][0] = 0;

We also set our base case, with a cost of 0, as there are no cost associated with starting at the starting city. City A (city 0) is represented by subset 1 (0001), a subset containing only this city.

Now we need to populate the DP table with the corrects costs for each route. We do this by iterating over all subset of cities.

for (int mask = 1; mask < (1 << n); mask++) {
    if ((mask & 1) == 0) continue; // Ensure city 0 is always in the subset

for every subset we to iterate over all its potential final cities. We check if a city is in the subset by doing mask & 1 << city.

for (var city = 1; city < n; city++) {
    if ((mask & 1 << city) == 0) continue; // Skip if city is not in the subset

Now, to calculate the cost of this route, we need to get the current subset without the current city. We do this with mask ^ (1 << city). Then we compute its cost plus the distance to current city, fo every possible ending city in that subset. The minimum value will be the cost for the current subset ending in the current city.

int prevMask = mask ^ (1 << city);

for (var lastCity = 0; lastCity < n; lastCity++) {
    if ((prevMask & 1 << lastCity) == 0) continue; // Skip if lastCity is not in prevMask

var distance = dp[prevMask][lastCity] == Integer.MAX_VALUE ?
        Integer.MAX_VALUE :
        dp[prevMask][lastCity] + distanceMatrix[lastCity][city];

if (distance < dp[mask][city]) {
    dp[mask][city] = distance;
    parent[mask][city] = lastCity;
}

Notice that we are storing the last city used for this route in the parent matrix. We will use that in the future when reconstructing the best route.

To find the best route, we get the subset that includes all cities and calculate its final cost, meaning the cost to end in every possible city plus the distance from that city to city A.

int mask = (1 << n) - 1; // All cities included
int lastCity = 0;
int shortestDistance = Integer.MAX_VALUE;

for (int i = 1; i < n; i++) {
    int routeCost = dp[mask][i] + distanceMatrix[i][0];
    if (routeCost < shortestDistance) {
        shortestDistance = routeCost;
        lastCity = i;
    }
}

Knowing the best route, and the city where it ends, we can start reconstructing the complete path.

int[] bestRoute = new int[n + 1];

for (int i = n - 1; i > 0; i--) {
    bestRoute[i] = lastCity;
    lastCity = parent[mask][lastCity];
    mask ^= (1 << bestRoute[i]); // Remove lastCity from the subset
}

This is how the final implementation should look like.

public class HeldKarpSolver implements TspSolver {
    @Override
    public String getName() {
        return "Held-Karp";
    }

    @Override
    public int[] solve(int[][] distanceMatrix) {
        var n = distanceMatrix.length; // Number of cities
        var dp = new int[1 << n][n]; // The dynamic programming table
        var parent = new int[1 << n][n]; // Stores the optimal end city from previous subsets

        // Initialize DP table with infinity
        for (var i = 0; i < (1 << n); i++) {
            Arrays.fill(dp[i], Integer.MAX_VALUE);
        }

        // Base case: city 0 is the starting point and the total distance of this subset is 0.
        dp[1][0] = 0;

        // Iterate over all subsets of cities, where mask is the bitmask of the subset
        for (int mask = 1; mask < (1 << n); mask++) {

            // Since we always start from city 0, we only consider subsets where it is present.
            if ((mask & 1) == 0) continue;

            // Iterate over all possible final cities from this subset to calculate subset distances
            // Since city 0 will never be the final city of the subset, we start fromm city 1
            for (var city = 1; city < n; city++) {

                // Check if city is in subset
                if ((mask & 1 << city) == 0) continue;

                // Gets a subset of the current subset where the current city is not present
                int prevMask = mask ^ (1 << city);

                // Iterate over all possible final cities from previous subset to find the best final city
                // Since previous subset could also be just the city 0, we start this iteration from 0
                for (var lastCity = 0; lastCity < n; lastCity++) {
                    if ((prevMask & 1 << lastCity) == 0) continue;

                    var distance = dp[prevMask][lastCity] == Integer.MAX_VALUE ?
                            Integer.MAX_VALUE :
                            dp[prevMask][lastCity] + distanceMatrix[lastCity][city];

                    if (distance < dp[mask][city]){
                        dp[mask][city] = distance;
                        parent[mask][city] = lastCity;
                    }
                }
            }
        }

        // Find the minimum cost of returning to the starting city
        int mask = (1 << n) - 1;
        int lastCity = 0;
        int shortestDistance = Integer.MAX_VALUE;

        for (int i = 1; i < n; i++) {
            int routeCost = dp[mask][i] + distanceMatrix[i][0];

            if (routeCost < shortestDistance) {
                shortestDistance = routeCost;
                lastCity = i;
            }
        }

        // Reconstruct the path moving backwards
        int[] bestRoute = new int[n + 1];
        for (int i = n - 1; i > 0; i--) {
            bestRoute[i] = lastCity;
            lastCity = parent[mask][lastCity];

            // After adding last city to the route, we get the subset where it is missing
            mask ^= (1 << bestRoute[i]);
        }

        return bestRoute;
    }
}

Strengths and Limitations

Strengths

1. Guarantees Optimality:
   Like brute force, the Held-Karp algorithm ensures the shortest possible route is found. It’s a powerful method for solving small to medium-sized Traveling Salesman Problem (TSP) instances.

2. Improved Efficiency Over Brute Force:
   While brute force has O(n!) time complexity, Held-Karp reduces this to O(n²⋅2^n), which is significantly faster for larger m.

3. Scales Better for Medium-Sized Problems:
   Practical for n≤20~30, depending on available memory and computational resources.

Limitations

1. Exponential Time Complexity:
   Despite being more efficient than brute force, Held-Karp still has exponential growth in runtime due to the 2^n subsets. This makes it impractical for n>30 in most cases.

2. High Memory Usage:
   The O(n²⋅2^n) space complexity requires storing results for all subsets of cities and possible end cities. Memory usage grows exponentially as n increases.

3. Implementation Complexity:
   Compared to brute force, Held-Karp is more challenging to implement due to its reliance on bitmasking and dynamic programming.

Branch and Bound: A Smarter Brute Force

The Branch and Bound (B&B) method is an optimization algorithm that builds on brute force by significantly reducing the number of paths explored. It does this by:

1. Branching: Systematically dividing the problem into smaller subproblems (branches).

2. Bounding: Calculating an optimistic lower bound for each branch to determine if it’s worth exploring further.

If the lower bound of a branch exceeds the current best solution, that branch is pruned (skipped), saving computation time.

How It Works

1. Initial Setup:
   Start with all cities and consider the initial city (e.g., A) as the root node of a search tree. Each branch represents a potential route to explore.

2. Branching:
   At each level of the tree, add one city to the current path, generating new branches. Continue branching until a complete tour is formed.

3. Bounding:
   For each branch, calculate a lower bound on the possible total cost of completing the tour. The lower bound is an estimate of the minimum possible cost, considering the current partial path and the best-case scenario for the remaining cities.

4. Pruning:
   If the lower bound of a branch is greater than or equal to the cost of the current best solution, discard that branch. Otherwise, explore it further.

5. Complete and Compare:
   When a complete tour is found, compare its cost to the current best solution. Update the best solution if the new tour has a lower cost.

Why It’s Better than Brute Force

• Brute Force explores all possible routes exhaustively, while Branch and Bound prunes unnecessary branches early.

• For nnn cities, brute force evaluates n!n!n! routes, whereas B&B evaluates only a subset of promising routes, reducing computational effort significantly.

Example Walkthrough

Let’s use the same example we used for the other methods.

• Root Node:
  Start at city A (0). The lower bound is calculated based on the minimum outgoing edges for all cities:

  • From A: Min(10, 15, 20) = 10.

  • From B: Min(10, 25, 35) = 10.

  • From C: Min(15, 30, 35) = 15.

  • From D: Min(20, 25, 30) = 20.
    Total lower bound:

$$\frac{10 + 10 + 15 + 20}{2} = 27.5$$

Branching begins by selecting the next city to visit.

• First Branch:
  A → B. The new lower bound is calculated based on the remaining cities (C, D). If the lower bound is higher than the current best solution, this branch is pruned.

• Continue Branching:
  Evaluate branches like A → B → C and A → B → D, calculating lower bounds for each. Prune branches as necessary.

• Completion:
  Once a complete tour is found (e.g., A → B → C → D → A), compare its cost to the current best solution and update if it’s better.

Implementation

Now let’s implement our new Branch & Bound solver. As always, we begin initializing the main variable we’ll be using throught the method.

var route = new int[distanceMatrix.length + 1];
var bestRoute = new int[distanceMatrix.length + 1];
var visited = new boolean[distanceMatrix.length];
var cities = new int[distanceMatrix.length];

for (int i = 0; i < distanceMatrix.length; i++) {
    cities[i] = i;
}

Now to thet actuallogic. This method is a modification of the Brute Force methd and you will notice some similarities. The difference relies in the fact that we calculate the route cost while we create the route and compare it with the the best value we’ve got so far. If it’s not smalles than the best value, then we move on to the next iteration.

if (level == cities.length) {
    int totalCost = currentCost + distanceMatrix[currentCity][0];
    if (totalCost < minCost.get()) {
        minCost.set(totalCost);
        System.arraycopy(currentPath, 0, bestRoute, 0, cities.length);
    }
    return;
}

We also perform this check earlier in the permutation, using the lower bound technique.

for (var nextCity = 0; nextCity < cities.length; nextCity++) {
    if (!visited[nextCity]) {
        var newCost = currentCost + distanceMatrix[currentCity][nextCity];
        var lowerBound = getBound(nextCity, cities, visited, distanceMatrix);

        // Prune if the new lower bound is not promising
        if (newCost + lowerBound < minCost.get()) {
            visited[nextCity] = true;
            currentPath[level] = nextCity;
            branchAndBound(nextCity, newCost, level + 1, currentPath, cities, visited, distanceMatrix, minCost, bestRoute);
            visited[nextCity] = false; // Backtrack
            currentPath[level] = 0;
        }
    }
}

The lower bound is calculated with the help of two auxiliar methods.

private double getBound(int candidateCity, int[] cities, boolean[] visited, int[][] distanceMatrix) {
    return (double) Arrays.stream(cities)
        .filter(x -> !visited[x])
        .map(x -> getMinEdgeCost(x, candidateCity, visited, distanceMatrix))
        .sum() / 2;
}

private int getMinEdgeCost(int city, int candidateCity, boolean[] visited, int[][] distanceMatrix) {
    var cost = IntStream.range(0, distanceMatrix.length)
        .filter(i -> i != city && (!visited[i] || i == 0) && i != candidateCity)
        .map(x -> distanceMatrix[city][x])
        .min();
    return cost.isPresent() ? cost.getAsInt() : 0;
}

The finalimplementation should look like this.

public class BranchAndBoundSolver implements TspSolver {
    @Override
    public String getName() {
        return "BranchAndBound";
    }

    @Override
    public int[] solve(int[][] distanceMatrix) {
        var cities = new int[distanceMatrix.length];
        for (int i = 0; i < distanceMatrix.length; i++) {
            cities[i] = i;
        }

        var route = new int[distanceMatrix.length + 1];
        var bestRoute = new int[distanceMatrix.length + 1];
        var visited = new boolean[distanceMatrix.length];
        visited[0] = true;

        branchAndBound(
                0,
                0,
                1,
                route,
                cities,
                visited,
                distanceMatrix,
                new AtomicInteger(Integer.MAX_VALUE),
                bestRoute);

        return bestRoute;
    }

    private void branchAndBound(
            int currentCity,
            int currentCost,
            int level,
            int[] currentPath,
            int[] cities,
            boolean[] visited,
            int[][] distanceMatrix,
            AtomicInteger minCost,
            int[] bestRoute) {

        if (level == cities.length) {
            // Complete the cycle back to the starting city
            int totalCost = currentCost + distanceMatrix[currentCity][0];
            if (totalCost < minCost.get()) {
                minCost.set(totalCost);
                System.arraycopy(currentPath, 0, bestRoute, 0, cities.length);
            }
            return;
        }

        for (var nextCity = 0; nextCity < cities.length; nextCity++) {
            if (!visited[nextCity]) {
                var newCost = currentCost + distanceMatrix[currentCity][nextCity];
                var lowerBound = getBound(nextCity, cities, visited, distanceMatrix);

                // Prune if the new lower bound is not promising
                if (newCost + lowerBound < minCost.get()) {
                    visited[nextCity] = true;
                    currentPath[level] = nextCity;
                    branchAndBound(nextCity, newCost, level + 1, currentPath, cities, visited, distanceMatrix, minCost, bestRoute);
                    visited[nextCity] = false; // Backtrack
                    currentPath[level] = 0;
                }
            }
        }

    }

    private double getBound(int candidateCity, int[] cities, boolean[] visited, int[][] distanceMatrix) {
        return (double) Arrays.stream(cities).filter(x -> !visited[x]).map(x -> getMinEdgeCost(x, candidateCity, visited, distanceMatrix)).sum() / 2;
    }

    private int getMinEdgeCost(int city, int candidateCity, boolean[] visited, int[][] distanceMatrix){
        var cost = IntStream.range(0, distanceMatrix.length)
                .filter(i -> i != city && (!visited[i] || i == 0) && i != candidateCity)
                .map(x -> distanceMatrix[city][x])
                .min();
        return cost.isPresent() ? cost.getAsInt() : 0;
    }

Strengths of Branch and Bound

1. Guaranteed Optimality:
   Like brute force, Branch and Bound finds the exact optimal solution for the Traveling Salesman Problem (TSP), making it a reliable choice when accuracy is critical.

2. Effective Pruning:
   By leveraging lower bounds to prune unpromising branches, B&B significantly reduces the number of paths explored compared to brute force.

3. Flexibility in Lower Bound Heuristics:
   The algorithm allows for the use of different lower-bound techniques (e.g., reduced cost matrix, minimum spanning tree) to improve pruning efficiency.

4. Adaptable for Variants of TSP:
   Branch and Bound can be easily adapted to handle constraints like time windows, precedence relationships, or asymmetric costs.

5. Systematic Search:
   The algorithm explores solutions in a structured way, ensuring all possibilities are accounted for without unnecessary repetition.

Limitations

1. Exponential Time Complexity in the Worst Case:
   While pruning improves performance, the worst-case time complexity remains exponential (O(n!)) if most branches need to be explored.

2. Dependence on Lower Bound Quality:
   The efficiency of B&B heavily relies on the tightness of the lower bound. Poor lower bounds result in fewer pruned branches and increased runtime.

3. Memory Usage:
   Recursive implementations require additional memory for storing the search tree, current paths, visited states, and best solutions.

4. Scalability:
   B&B is impractical for large TSP instances (e.g., n>30) because the number of branches grows exponentially with the number of cities.

5. Computational Overhead for Lower Bound Calculation:
   Techniques like the reduced cost matrix or minimum spanning tree add computational overhead to each node evaluation, which may negate pruning gains in smaller problems.

Conclusion: Comparing Exact Methods for the Traveling Salesman Problem

In this post, we’ve explored three exact methods for solving the Traveling Salesman Problem (TSP): Brute Force, Held-Karp, and Branch and Bound. Each method guarantees an optimal solution but differs significantly in terms of performance, scalability, and practicality. Let’s summarize their strengths, limitations, and real-world applicability.

Brute Force: The Simplest Approach

Brute force explores every possible route (n!) to find the optimal solution. While easy to understand and implement, its exponential growth in computational time makes it impractical for more than 10 cities. For small problems, however, brute force may still be a viable option due to its simplicity.

Held-Karp: The Dynamic Programming Powerhouse

The Held-Karp algorithm improves on brute force with a time complexity of O(n²⋅2^n), reducing redundant calculations by leveraging dynamic programming. This method consistently outperforms both brute force and Branch and Bound for medium and large problem sizes, as evidenced by benchmark results.

From the chart, we see that Held-Karp scales much better than Branch and Bound for problems with more than 10-15 cities. Despite its high memory requirements, Held-Karp is the most practical exact method for problems with up to 20-25 cities.

Branch and Bound: Smart Pruning, Limited Scalability

Branch and Bound employs smart pruning to avoid evaluating unpromising routes. While it often outperforms brute force in small to medium-sized problems, its factorial complexity in worst-case scenarios limits its scalability. The effectiveness of this method depends heavily on the quality of the lower-bound heuristic, and as problem size increases, Held-Karp emerges as the better choice for exact solutions.

Choosing the Right Method

Based on the benchmarks and theoretical insights, here’s when to use each method:

• Brute Force: For very small problems (n≤10) where simplicity matters more than performance.

• Held-Karp: For medium to larger problems (n≤25) where memory constraints are manageable.

• Branch and Bound: For small to medium problems (n≤15) where a good lower-bound heuristic is available.

Final Thoughts

The chart below illustrates the performance of these methods as the number of cities increases. While Branch and Bound provides significant improvements over brute force for smaller inputs, Held-Karp consistently delivers better performance as problem size grows, solidifying its position as the most efficient exact algorithm for solving TSP.

When the number of cities exceeds 20-25, even Held-Karp becomes computationally expensive. At this point, approximate methods like Genetic Algorithms, Simulated Annealing, or Ant Colony Optimization are better alternatives.

By understanding the trade-offs of each method, you can make informed decisions about which approach to use based on your problem size and computational resources.

Imagine a salesperson who must travel to multiple cities, visiting each one exactly once before returning to their starting point. What’s the shortest route they can take? This seemingly simple question has puzzled mathematicians, computer scientists, and engineers for decades. Known as the Traveling Salesman Problem (TSP), it is one of the most well-known optimization problems in computer science, and its applications span industries as diverse as logistics, electronics, and bioinformatics.

What makes TSP particularly intriguing is not just its practical importance but also its computational complexity. As the number of cities increases, the possible routes grow exponentially, turning this problem into a classic example of an NP-hard challenge. Despite this, researchers have developed ingenious algorithms and heuristics to find efficient solutions, even for large-scale instances.

In this blog post, we’ll unravel the mysteries of TSP, explore its real-world applications, and take a closer look at the fascinating methods used to tackle this timeless problem. Whether you're a seasoned data scientist, a curious student, or simply someone intrigued by puzzles, the TSP offers valuable insights into the art and science of optimization.

What Is the Traveling Salesman Problem?

The Traveling Salesman Problem (TSP) is a fundamental optimization challenge with a deceptively simple goal:

What is the shortest route that visits a set of cities exactly once and returns to the starting point?

While the question is straightforward, solving it is anything but. The number of possible routes grows exponentially as cities are added, making brute-force solutions impractical for all but the smallest cases. TSP exemplifies the complexity of optimization problems and serves as a cornerstone in computer science and mathematics.

Let’s break it down step by step:

A Simple Example

Consider a salesperson visiting four cities: A, B, C, and D. They start at city A, visit each city once, and return to A. Below is a table showing the distances between the cities:

The salesperson could take one of the following routes:

1. A → B → C → D → A

2. A → B → D → C → A

3. A → C → B → D → A

4. A → C → D → B → A

5. A → D → B → C → A

6. A → D → C → B → A

Each route's total distance is calculated. For instance:
A → B → C → D → A = 10 + 35 + 30 + 20 = 95 units

With just four cities, there are 6 routes to evaluate. But as the number of cities grows, the total routes explode factorially. For n cities, the possibilities are (n−1)!, making brute-force computation impractical for large problems.

The Goal of TSP

The Traveling Salesman Problem seeks the optimal route—the shortest possible path that visits all cities exactly once and returns to the starting point. Depending on the context, the "shortest" route might optimize other factors like travel time or cost instead of physical distance.

Types of TSP

Depending on the scenario, TSP can take different forms:

1. Symmetric TSP: The distance between two cities is the same in both directions (e.g., traveling from A to B is the same as from B to A).

2. Asymmetric TSP: The distance between two cities may differ depending on the direction (e.g., one-way roads or different traffic conditions).

The Traveling Salesman Problem is deceptively simple but incredibly profound. Its beauty lies in its universality: from mapping delivery routes to sequencing DNA, the principles behind TSP find applications across a wide range of fields. However, solving it efficiently remains one of the great challenges of computational science.

Why Is the Traveling Salesman Problem Important?

The Traveling Salesman Problem (TSP) is more than a theoretical puzzle. It’s a cornerstone in optimization, with wide-ranging applications and significant influence on computational theory.

1. Real-World Applications

TSP has practical uses in countless industries where optimizing routes, sequences, or schedules is essential. Here are some notable examples:

• Logistics: Delivery companies like UPS and Amazon use TSP-like solutions to optimize routes, saving fuel, time, and costs.

• Manufacturing: In PCB production, TSP minimizes the movement of drill heads or lasers, improving efficiency.

• Bioinformatics: Researchers optimize DNA sequencing by arranging fragments to minimize mismatches.

• Travel and Scheduling: TSP helps plan efficient travel itineraries and sports tournament schedules.

2. TSP as a Gateway to Complex Problems

TSP principles extend to more complex problems, such as:

• Vehicle Routing Problem (VRP): Optimizing routes for fleets of vehicles with constraints like time windows or capacity limits.

• Job Scheduling: Sequencing tasks in manufacturing or IT to minimize costs or delays.

• Network Design: Minimizing connection costs in data or telecommunication networks.

3. Theoretical Significance

TSP’s study has advanced algorithms and our understanding of computational complexity:

• NP-Hardness: TSP exemplifies the difficulty of NP-hard problems, where verifying a solution is easy, but finding one is computationally intense.

• Algorithm Innovation: Research has led to breakthroughs in dynamic programming, branch-and-bound techniques, and heuristic methods.

• Broader Insights: Approximation and heuristic methods inspired by TSP are now applied to many real-world challenges.

4. Broader Implications

TSP is important also for what it symbolizes: the balance between simplicity and complexity. It challenges us to find innovative ways to deal with exponential growth and teaches us how to make trade-offs between computational resources and solution quality.

Additionally, TSP serves as a platform for interdisciplinary collaboration. Mathematicians, computer scientists, engineers, and professionals from logistics, biology, and even the arts come together to tackle problems inspired by TSP, fostering innovation across fields.

The Complexity of the Traveling Salesman Problem

The TSP is deceptively simple yet incredibly complex. While its premise is easy to understand, the problem’s exponential growth in possibilities makes solving it a formidable challenge.

1. Exponential Growth of Possibilities

1. Exponential Growth of Possibilities

For nnn cities, the number of possible routes is (n−1)!(n-1)!(n−1)!, growing factorially:

• 4 cities: 666 routes

• 10 cities: 362,880362,880362,880 routes

• 20 cities: 121,645,100,408,832,000121,645,100,408,832,000121,645,100,408,832,000 routes

This rapid growth makes brute-force solutions impractical, even for moderate-sized problems.

2. NP-Hardness: Why TSP Is Hard to Solve

TSP belongs to the NP-hard class of problems, where verifying a solution is quick, but finding one is computationally expensive. This means no efficient algorithm is known for solving all TSP instances in polynomial time. TSP also serves as a benchmark problem for understanding computational limits in fields like cryptography and artificial intelligence.

3. Exact Solutions vs. Approximation

Given the computational challenges, solving TSP can be approached in two main ways:

1. Exact Methods:

   • These algorithms guarantee the shortest possible route but are computationally expensive, especially for large datasets. Examples include:

     • Brute Force: Tests every possible route (impractical for large datasets).

     • Dynamic Programming (Held-Karp Algorithm): Reduces redundant calculations but still requires exponential time (O(n2⋅2n)O(n^2 \cdot 2^n)).

     • Branch and Bound: Systematically eliminates suboptimal solutions but suffers from exponential worst-case performance.

2. Approximation and Heuristics:

   • Approximation algorithms and heuristics trade precision for speed, providing "good enough" solutions in reasonable timeframes. For instance:

     • Nearest Neighbor Heuristic: Starts at a city and repeatedly visits the nearest unvisited city.

     • Christofides’ Algorithm: Guarantees a solution within 1.5 times the optimal route for symmetric TSP.

     • Genetic Algorithms and Simulated Annealing: Explore large solution spaces using probabilistic methods.

4. Computational Challenges in Practice

While theoretical solutions exist, real-world TSP problems often introduce additional complexities that make solving them even harder:

• Dynamic Conditions: In logistics, traffic, weather, or delivery time windows can change during computation.

• Asymmetry: Distances may vary depending on direction (e.g., one-way streets or varying traffic conditions).

• Constraints: Real-world problems like the Vehicle Routing Problem (VRP) add restrictions like vehicle capacities or time limits, complicating the optimization further.

5. The Search for Efficiency: Research and Innovations

The challenge of solving TSP has spurred decades of research into optimization, resulting in innovative approaches like:

• Cutting-Plane Methods: Used in integer programming to iteratively refine solutions.

• Parallel Computing: Distributes computations across multiple processors to handle larger datasets.

• Quantum Computing: Promises revolutionary speedups for TSP-like problems using quantum algorithms (e.g., Grover’s algorithm for searching).

Despite these advancements, the exponential nature of TSP ensures that it remains a computational challenge at its core.

Approaches to Solving the Traveling Salesman Problem

Over the years, researchers have developed various approaches to solve the TSP, ranging from exact solutions to approximations and metaheuristics. Each method strikes a balance between precision and computational feasibility, depending on the problem size and constraints.

1. Exact Solutions

These approaches guarantee the shortest route but are computationally expensive, making them ideal for smaller datasets or where precision is critical.

Brute Force

The most straightforward (and impractical) method is to calculate the distance of every possible route and select the shortest. For n cities, this requires checking (n−1)! routes.

Dynamic Programming: Held-Karp Algorithm

This algorithm reduces redundant calculations by storing intermediate results. It achieves a time complexity of O(n2⋅2n), which is an improvement over brute force but still exponential.

Branch and Bound

This technique eliminates large portions of the search space by "bounding" the cost of suboptimal routes.

2. Approximation Algorithms

Approximation algorithms provide near-optimal solutions efficiently, often trading accuracy for speed.

Nearest Neighbor Algorithm

Start at a random city and repeatedly visit the nearest unvisited city until all are covered. This method is fast but prone to suboptimal routes.

Minimum Spanning Tree (MST) Heuristic

This algorithm constructs a tree that connects all cities with the minimum total edge weight, then derives a TSP route.

Christofides’ Algorithm

For symmetric TSP, Christofides’ Algorithm guarantees a solution within 1.5 times the optimal distance.

3. Metaheuristic Algorithms

Metaheuristics intelligently explore the solution space and are effective for large, complex instances.

Genetic Algorithms (GA)

Mimic evolution through selection, crossover, and mutation to iteratively improve routes.

Simulated Annealing (SA)

This algorithm mimics the process of cooling metal to gradually reduce randomness in exploring solutions.

Ant Colony Optimization (ACO)

Inspired by the behavior of ants, ACO uses "pheromone trails" to explore and optimize routes.

4. Hybrid Methods

Combining methods often yields the best results. For instance, metaheuristics like ACO can identify good initial solutions, which are then refined using exact methods like dynamic programming.

5. Quantum Computing

Quantum computing offers promising new methods for TSP. Quantum annealers like D-Wave and quantum algorithms (e.g., Grover’s search) aim to solve optimization problems more efficiently than classical counterparts.

Conclusion

The Traveling Salesman Problem is a remarkable challenge that bridges the gap between theory and real-world problem-solving. Its deceptively simple premise has inspired decades of research, leading to advancements in optimization algorithms, computational theory, and practical applications across industries. Whether it’s improving logistics, sequencing DNA, or exploring complex networks, TSP demonstrates the power and creativity of algorithmic thinking.

In the next post, we’ll dive into exact methods for solving TSP, exploring how these approaches provide optimal solutions while highlighting their limitations. Stay tuned as we continue unraveling the intricacies of this timeless problem.

But what exactly does it mean for a class to have only one responsibility? And why is it so crucial in the realm of software engineering? The concept of a "single responsibility" can be somewhat abstract, but it can be broken down into more tangible terms. A responsibility is considered a reason for change. When a class has more than one responsibility, those responsibilities become coupled. A change to one responsibility may affect the other, leading to an increase in the likelihood of bugs and a decrease in the ease of understanding and maintaining the code. For instance, consider a class that handles both the user interface logic and the data processing logic. Changes to the data processing requirements might inadvertently impact the user interface code, leading to unexpected issues. By adhering to SRP, these responsibilities would be separated into different classes, isolating the potential for unintended side effects and making the system more modular.

The benefits of SRP extend beyond just reducing bugs and improving code clarity. It also enhances the ability to reuse classes and components across different parts of an application or even in different projects. When a class has a single responsibility, it is easier to see its purpose and potential applications in other contexts. Moreover, such classes tend to be smaller and more focused, making them easier to unit test. By ensuring that each class has a distinct and clear responsibility, developers can build more robust and flexible systems that are easier to extend and modify over time. This leads to more efficient development processes and a higher overall quality of the software product.

Example

Ok, let’s dive in a practical example to see how SRP should look like.

The User Management Service

1. Without SRP

public class UserManager
{
    public void CreateUser(string username, string password)
    {
        // Validate user input
        if (username == null || password == null)
        {
            throw new ArgumentException("Username and password cannot be null");
        }

        // Hash the password
        var hashedPassword = HashPassword(password);

        // Save user to the database
        SaveUserToDatabase(username, hashedPassword);

        // Send a welcome email
        SendWelcomeEmail(username);
    }

    private string HashPassword(string password)
    {
        // Hashing logic here
        return "hashedPassword";
    }

    private void SaveUserToDatabase(string username, string hashedPassword)
    {
        // Database save logic here
    }

    private void SendWelcomeEmail(string username)
    {
        // Email sending logic here
    }
}

As we can see, the UserManager class is responsible for multiple tasks: validating user input, hashing passwords, saving user data to the database, and sending emails. This makes the class large and complex, which reduces its readability and makes it harder to understand what the class is supposed to do at a glance. Also, since UserManager class handles multiple responsibilities, any change in one responsibility might affect the others. Over time, as more changes are made, the class can become increasingly fragile and harder to maintain. Testing this class might also be a challenge, as one would need to take into accountb all the responsibilities of this class, which increases the complexity of the test.

2. With SRP

public class UserValidator
{
    public void Validate(string username, string password)
    {
        if (username == null || password == null)
        {
            throw new ArgumentException("Username and password cannot be null");
        }
    }
}

public class PasswordHasher
{
    public string HashPassword(string password)
    {
        // Hashing logic here
        return "hashedPassword";
    }
}

public class UserRepository
{
    public void SaveUser(string username, string hashedPassword)
    {
        // Database save logic here
    }
}

public class EmailService
{
    public void SendWelcomeEmail(string username)
    {
        // Email sending logic here
    }
}

public class UserManager
{
    private readonly UserValidator _validator;
    private readonly PasswordHasher _hasher;
    private readonly UserRepository _repository;
    private readonly EmailService _emailService;

    public UserManager()
    {
        _validator = new UserValidator();
        _hasher = new PasswordHasher();
        _repository = new UserRepository();
        _emailService = new EmailService();
    }

    public void CreateUser(string username, string password)
    {
        _validator.Validate(username, password);
        var hashedPassword = _hasher.HashPassword(password);
        _repository.SaveUser(username, hashedPassword);
        _emailService.SendWelcomeEmail(username);
    }
}

Now, this version of the code looks better. Each of the UserManager responsibilities were extracted into separated classes. This makes it easier to understand and maintain each of the classes, as well as test them. Some of the classes, like the EmailServer, now can be reused someqhere else in the application if needed. The UserManager class itself becomes just, well, a manager. It is the one that knows the other classes and knows when to call them.

Identifying SRP violations

Ok, we are all now aware that SRP is super great. But how can we identify violations of this priciple in our code? I’ll list some tips that might help.

1. Analyze Class Responsibilities This one is kinda obvious, right? But we have to begin somewhere. Examine each class and list all the functionalities it implements. Sometimes classes can have more than one functionality, if they are closely related to each toher. We also need to evaluate cohesion here. Classes will have multiple methods, each doing something different, and that’s what’s expected of a clas. What we have to look for is lack of cohesion between these methods. A highly cohesive class has methods and attributes that are directly related to each other. Low cohesion, where methods and attributes serve disparate purposes, indicates a violation of SRP.

2. Check for Multiple Reasons to Change According to the SRP, a class should have only one reason to change. If you find that modifications to different aspects of your application (e.g., changes in business rules, data format, or user interface) all require changes to the same class, SRP is likely being violated. This indicates that the class has multiple responsibilities.

3. Monitor Class Size and Complexity Large classes with many methods and attributes often signal SRP violations. While size alone is not a definitive indicator, complexity usually accompanies size. If a class is doing too much, it becomes harder to understand and maintain. Consider refactoring large classes into smaller, more focused ones.

4. Consider Testing Challenges If writing unit tests for a class is difficult, it may be due to SRP violations. Classes with multiple responsibilities require more complex tests that cover all possible interactions and side effects. Simplifying classes by ensuring they adhere to SRP will result in simpler, more focused tests.

By using these strategies, developers can systematically identify and address SRP violations, leading to cleaner, more maintainable codebases.

Conclusion

I hope this text has helped you to better understand the SIngle Responsibility Pinciple (SRP), one of the fundameltal guidelines in software design. By recognizing and rectifying SRP violations—through analyzing class responsibilities, checking for multiple reasons to change, reviewing method groupings, monitoring class size and complexity, evaluating cohesion, and considering testing challenges—you will be able to significantly improve the quality of your code. Embracing SRP not only simplifies the development process but also enhances the scalability and robustness of software applications, ultimately leading to more efficient and effective coding practices.