Exploration · 001-find-the-shortest-path-between-two · Quarantined

find the shortest path between two nodes in a small weighted graph

A build-to-learn record. Loose by design — graduate or delete; nothing here ships un-graduated.

Status

Quarantined

Explore ID001-find-the-shortest-path-between-two Intent find the shortest path between two nodes in a small weighted graph Created 23 Jul 2026 Exits graduate (→ spec/design/tasks) · delete

1 · Intent

find the shortest path between two nodes in a small weighted graph

The one thing I want to know at the end: does “shortest” here mean the fewest hops or the least total weight? They're the same on an unweighted graph and can diverge sharply on a weighted one — and which one it is decides the algorithm. I'll build to find out, not argue about it.

2 · What I built / tried / worked / didn't

Keep it rough. This is the discovery log — the value is the learning, not the prose.

Built

graph.ts — an undirected weighted adjacency map + a cost() helper that sums a path's weight. One SAMPLE graph (5 nodes) deliberately rigged so the cheapest route takes the most hops.
bfs.ts — breadth-first search: shortest path by edge count, weight-blind.
dijkstra.ts — shortest path by total weight, plain linear-scan frontier.
probe.ts — runs both on the same graph, prints each path with its real weight, and asserts Dijkstra is strictly cheaper. Run with a bare node probe.ts (Node 25 runs the TS directly).

Tried

BFS first — my gut said “shortest = fewest steps,” and BFS is the textbook fewest-edges answer.
Then Dijkstra, the moment the probe showed BFS and Dijkstra disagreeing on the real cost.
Considered a binary-heap frontier; at 5 nodes a linear scan is plainly enough, so I left it (noted to harden).

Worked

Dijkstra returns A → B → C → D → E at cost 6 — the genuine least-weight path.
The probe makes the ambiguity concrete instead of theoretical: the two algorithms visibly disagree.
No build step — Node's native TS stripping runs the spike as-is, which kept the loop tight.

Didn't

BFS is wrong for this problem: weight-blind, it took the 2-hop route A → C → E at cost 25 — the most expensive path on the board.
No negative-weight handling — out of scope here; that would need Bellman-Ford, not Dijkstra.
No priority-queue frontier yet — fine at this size, but the obvious first hardening step for the design.

3 · What actually ran

The commands you ran and what they proved. Captured in the verify.html Run/Demo shape so a later graduation can promote these facts to grounding="verified" with no re-capture.

node probe.ts

none

node probe.ts — exits non-zero unless Dijkstra's path is strictly cheaper than BFS's (one inline assertion; not a suite yet)

On the weighted sample, shortest A → E: BFS returns A → C → E (2 hops, cost 25) while Dijkstra returns A → B → C → D → E (cost 6). They disagree by 19 — proving “shortest” means least weight, not fewest hops. Verdict: keep Dijkstra, graduate as a tracer-bullet.