Evaluation of Dijkstra’s Algorithm

1. Implementing Dijkstra's algorithm on simple weighted graphs

Graph Reading & Construction:
This program correctly reads a graph from text files; outputs the number of vertices and edges in both
graphs and the adjacency list format is displayed; confirming correct graph parsing.

Algorithm Execution:
The algorithm uses a binary heap (priority queue via heapq)​
It maintains a dictionary where:
●​ Keys are vertices
●​ Values are tuples containing the shortest path distance and the preceding vertex

Instructions to run the code:

●​ Place the input files in the same directory as the script and use the graphreader() function to read
the graph and assign it to a variable.
●​ Let's just say the variable name is graph1.
●​ Graph1’s source and destination is then found by using the .get_vertex_by_label() function.
●​ Print the shortest path with the result after running dijkstra(graph1, source1, destination1) which
we can then print with source1 and destination1.
●​ Do the same for simplegraph2.

Results for simplegraph1.txt:

●​ The shortest path from V1 to V4 is found.

●​ The cost is 8, which matches the expected result.
●​ Preceding vertex on this path is V3, which is also correct.

Results for simplegraph2.txt:

●​ The shortest path from 14 to 5 is computed.

●​ The cost is 16, as expected.
●​ The preceding vertex on this path is 8, confirming correctness.
 Evaluation of Dijkstra’s Algorithm
2. Generating random graphs

Grid Graph Generation:

●​ You implemented a function generate_grid_graph(n, m) that:

○​ Creates an n x m grid where each node is represented as (i, j).
○​ Connects nodes to their right ([i][j+1]) and bottom ([i+1][j]) neighbors if they exist.
○​ Assigns random edge weights in the range 1 to max(n, m) //

Execution on a 4x4 Grid Graph:

●​ Your test case successfully generates a 4x4 grid.

●​ The shortest path computation from (0,0) to (3,3) is performed using Dijkstra's Algorithm.
●​ The output lists:
○​ Vertices in the shortest path.
○​ Path cost from the source (0,0).
○​ Preceding vertex, forming the shortest route.

Instructions to run the code:

-​ Test on a 4x4 grid graph.

-​ Assign graph, source, destination = generate_graph_grid(4, 4)
-​ Run dijkstra with these inputs and we should receive the shortest path in a 4x4 grid graph.

Correctness Verification:

●​ The path length at (3,3) is 7, meaning Dijkstra’s algorithm is correctly summing up the shortest
distances.
●​ The step-by-step path is printed, showing logical progression.
 Evaluation of Dijkstra’s Algorithm

3. Evaluate the runtime of Dijkstra as the size of the grid graph increases

Runtime Evaluation Setup:

●​ Function evaluate_dijkstra(grid_sizes, num_trials=10):

○​ Iterates through multiple grid sizes.
○​ Runs Dijkstra’s algorithm 10 times per grid size.
○​ Computes average runtime over those trials.
○​ Prints:
■​ Grid size (n x m).
■​ Average runtime.
■​ Shortest path length.

Grid Sizes Tested:

●​ (4x4), (8x8), (16x16), (32x32), (64x64)

●​ For each size, average runtime and shortest path length are recorded.

Runtime Trends Observed:

Grid Size Avg Runtime (seconds) Shortest Path Length

4x4 0.000000 5

8x8 0.000000 14

16x16 0.000913 49

32x32 0.005463 139

64x64 0.022014 546

●​ Runtime increases with grid size

●​ Path length grows as expected, confirming correctness.
 Evaluation of Dijkstra’s Algorithm

Analysis of Runtime Patterns

1. Dijkstra’s Algorithm Complexity:

●​ Dijkstra’s using a binary heap (priority queue) runs in O((n×m) log(n×m)).

●​ Larger grids → More nodes → More operations.

2. Key Observations:

●​ Doubling the grid size → Runtime grows more than linearly.

●​ 64x64 takes ~20ms, which is reasonable but grows quickly.

3. Factors Affecting Performance:

●​ Priority Queue Implementation (APQ)

○​ If implemented with a binary heap, it’s O(log V) per operation.
○​ If a naive list is used, performance can degrade to O(V²).
 Evaluation of Dijkstra’s Algorithm
4. Evaluating the impact of finding the shortest path to all other nodes

Instructions for Running the Evaluation:

●​ Run the script assignmentq4.py in VS Code:

●​ The program will generate a 500x500 grid graph.
●​ The source node is fixed at (250,250).
●​ The script runs Dijkstra’s algorithm:
○​ Once for all nodes.
○​ Once for a specific destination.
●​ Results are displayed for increasing destination distances.

Key Observations:

●​ For shorter distances (≤250):

○​ The specific destination approach is significantly faster.
○​ It avoids unnecessary computations beyond the needed path.
○​ Example: At distance = 50, specific destination is 5.5x faster.
●​ For medium distances (250-350):
○​ The performance gap narrows.
○​ The cost of checking for the specific destination catches up with the full search.
 Evaluation of Dijkstra’s Algorithm
●​ For larger distances (≥400):
○​ The two runtimes become nearly identical.
○​ At distance = 450, the specific destination approach is slightly slower.
○​ This suggests that past a certain range, Dijkstra’s full search tree is more
efficient.

Conclusion:

●​ The cross-over point appears around distance 400-450.

●​ For short paths, using a specific destination check is beneficial.
●​ For longer paths, computing all nodes may be just as efficient (or even slightly better).

5. Evaluating the impact of the binary heap APQ versus the unsorted list
APQ.

Instructions for Running the Evaluation

●​ Ensure you have Python 3.11+ installed.

●​ Install any required dependencies (if applicable).
●​ Run the script assignmentq5.py in VS Code.
●​ The script generates random graphs of increasing sizes.
●​ Dijkstra’s algorithm is run using two different priority queue implementations:
○​ Binary Heap (Efficient priority queue)
○​ Unsorted List (Naïve priority queue)
●​ The runtime for both implementations is recorded and printed for comparison.
 Evaluation of Dijkstra’s Algorithm

Key Observations

1.​ For small grid sizes (50x50)​

○​ Both implementations are relatively fast.

○​ The unsorted list takes ~3.5x longer than the binary heap.

2.​ For medium grid sizes (100x100)​

○​ The binary heap remains efficient (0.0662s).

○​ The unsorted list becomes significantly slower (0.9318s, ~14x slower than the
heap).

3.​ For larger grid sizes (200x200 and beyond)​

○​ The difference in performance becomes extreme.

○​ At 200x200, the heap is ~17x faster.
○​ At 400x400, the heap runs in 1.4s, while the unsorted list takes over 32 seconds
(~23x slower!).

Conclusion

●​ The results strongly support using a binary heap for Dijkstra’s algorithm.
●​ The unsorted list struggles as the graph size grows, leading to exponential slowdowns.
●​ Why does this happen?
○​ A binary heap allows efficient insertions and deletions in O(log n) time.
○​ An unsorted list must search for the minimum element in O(n) time for every
extraction.
○​ As the graph grows, the heap scales efficiently, while the unsorted list struggles
under increasing load.

For real-world applications where speed matters, the binary heap is the clear winner. The
unsorted list is only useful for small graphs where implementation simplicity is more important
than performance.
 Evaluation of Dijkstra’s Algorithm
6. Evaluating a simpler priority queue

Implementation Overview

We compare two approaches to implementing Dijkstra’s Algorithm:

1.​ Standard Approach​

○​ Maintains a single entry per vertex in the priority queue (PQ).

○​ When a shorter path to a vertex is found, the entry is updated in the PQ.
○​ This requires a locations dictionary to track positions within the PQ.
2.​ Alternative Approach​

○​ Allows multiple entries per vertex in the PQ.

○​ When a shorter path is found, it is simply added to the PQ instead of updating.
○​ The first time a vertex is removed from the PQ, it is guaranteed to be its shortest
path.
○​ Later removals for the same vertex are ignored using a closed dictionary.
○​ This removes the need for a locations dictionary.
 Evaluation of Dijkstra’s Algorithm
Key Observations

1.​ The standard approach is faster (~2.63s vs. ~3.42s).​

○​ This is expected since it avoids unnecessary duplicate entries in the PQ.

2.​ The alternative approach is easier to implement but has a higher overhead​

○​ It avoids the need for a locations dictionary, simplifying code complexity.

○​ However, the trade-off is extra memory usage and slower execution due to
duplicate PQ entries.

3.​ The difference in runtime (~30% slower for the alternative approach) is noticeable.​

○​ This would become more significant for larger graphs.

Conclusion

●​ The standard approach is preferable for performance reasons, particularly for large-scale
graphs.

●​ The alternative approach is useful when implementation simplicity is more important than
execution time.

Final Thoughts:

●​ Data structures have a massive impact on algorithm efficiency.

●​ The binary heap is the clear winner for Dijkstra’s algorithm, ensuring fast performance
even on large graphs.

●​ Using an unsorted list for a priority queue quickly becomes impractical due to its poor
scaling.

●​ Allowing multiple entries in the PQ simplifies implementation but increases runtime.