More practice problems

Author: AustinTSchaffer

OMSCS/Courses/GA/Practice Problems/3.7 - Bipartite Graphs.md

@@ -3,6 +3,7 @@ tags:
   - OMSCS
   - Algorithms
   - Practice
+  - Alg-Graph
 ---
 # 3.7 - Bipartite Graphs
 ![[Pasted image 20260313092928.png]]

OMSCS/Courses/GA/Practice Problems/4.1 - Dijkstra Example.md

@@ -0,0 +1,68 @@
+---
+tags:
+  - OMSCS
+  - Algorithms
+  - Practice
+  - Alg-Graph
+---
+# 4.1 - Dijkstra Example
+![[Pasted image 20260314160848.png]]
+## Graph
+```mermaid
+graph LR
+
+A --1--> B
+A --4--> E
+A --8--> F
+
+E --5--> F
+
+B --6--> F
+B --2--> C
+B --6--> G
+
+C --1--> D
+C --2--> G
+
+D --1--> G
+D --4--> H
+
+G --1--> F
+G --1--> H
+```
+
+## 4.1a - Dijkstra Propagation
+| t=... | A   | B     | C     | D     | E     | F     | G     | H     |
+| ----- | --- | ----- | ----- | ----- | ----- | ----- | ----- | ----- |
+| 0     | 0   | inf   | inf   | inf   | inf   | inf   | inf   | inf   |
+| 1     | 0   | **1** | inf   | inf   | inf   | inf   | inf   | inf   |
+| 2     | 0   | 1     | **3** | inf   | inf   | inf   | inf   | inf   |
+| 3     | 0   | 1     | 3     | inf   | **4** | inf   | inf   | inf   |
+| 4     | 0   | 1     | 3     | **4** | 4     | inf   | inf   | inf   |
+| 5     | 0   | 1     | 3     | 4     | 4     | inf   | **5** | inf   |
+| 6     | 0   | 1     | 3     | 4     | 4     | **6** | 5     | inf   |
+| 7     | 0   | 1     | 3     | 4     | 4     | 6     | 5     | **6** |
+Note, there's a couple options here for propagation, but it depends on how the PQ is managed.
+
+- At t=3, we have the option of selecting AE or CD. This only affects the order in which those edges are selected. There are no other downstream consequences of this decision. I selected AE first, because it was discovered before CD.
+- At t=5, we have the option of selecting CG or DG. Both result in an $A \rightarrow G$ distance of 5. However, this does change the path length of $A \rightarrow G$, as well as the path lengths from $A \rightarrow F$ and $A \rightarrow H$. For this example graph, I selected CG because
+	- CG was discovered before DG
+	- It shortened the SP tree (below)
+
+## 4.1b - SP Tree
+```mermaid
+graph LR
+
+A --1--> B
+A --4--> E
+
+
+B --2--> C
+
+C --1--> D
+
+C --2--> G
+
+G --1--> F
+G --1--> H
+```

OMSCS/Courses/GA/Practice Problems/4.11 - Detect Cycles in Cubic Time.md

@@ -0,0 +1,40 @@
+---
+tags:
+  - OMSCS
+  - Algorithms
+  - Practice
+  - Alg-Graph
+---
+# 4.11 - Detect Cycles in Cubic Time
+> Give an algorithm that takes as input a directed graph with positive edge lengths, and returns the length of the shortest cycle in the graph (if the graph is acyclic, it should say so). Your algorithm should take time at most $O(|V|^3)$.
+
+## Exploration
+- We can check if the graph is a DAG by running SCC and seeing if $|V_{SCC}|=|V|$. If this is the case, then each metavertex in the SCC metatraph only contains one vertex, which means no vertices in $G$ are part of a cycle.
+- Running SCC on $G$ will produce subsets of vertices which within themselves contain cycles.
+- We can use the output of SCC to partition $G$ into $k$ subgraphs. $G_k$ is the subset of $G$ which comprises $v_{k} \in V_{SCC}$. If $v_k$ contains only 1 vertex, we skip it.
+
+There's a possibility that all of this ends up returning the exact same graph, so it's likely that none of it is needed. Also, this likely isn't a problem that's asking for the "shortest cycle" in terms of the number of edges. It's more likely that it's asking for the "shortest cycle" in terms of edge weights.
+
+Given the runtime hint, this is likely a Floyd-Warshall problem.
+## Algorithm
+Run Floyd-Warshall on the graph, producing a 2D distance array which maps the distance between every pair of vertices. For each pair of distinct vertices in the graph u and v, sum the distance from u to v and the distance from v to u. Take this minimum combined distance across G. The result is the minimum length cycle in G. If the minimum length cycle is infinite, then G is a DAG. Otherwise, return the length of the minimum cycle.
+## Justification
+This is a fairly simple adaptation of Floyd-Warshall. The only interesting part of this problem is detecting that G is a DAG. If G is a DAG, then for every pair of distinct vertices v and u, one of these must be true:
+
+1. u can reach v, but v cannot reach u
+	1. $dist[u][v] \ne \infty$
+	2. $dist[v][u] = \infty$
+2. v can reach u, but u cannot reach v
+	1. $dist[v][u] \ne \infty$
+	2. $dist[u][v] = \infty$
+3. Neither u can reach v, nor can v reach u
+	1. $dist[u][v] = \infty$
+	2. $dist[v][u] = \infty$
+
+Under all of these conditions, $dist[u][v]+dist[v][u]=\infty$. Therefore, the minimum distance pair is always $\infty$.
+
+## Runtime
+- Floyd-Warshall: $O(n^3)$
+- Minimum over $(u,v) \in V$: $O(n^2)$
+
+Overall: $O(n^3)$

OMSCS/Courses/GA/Practice Problems/4.12 - Shortest Cycle Containing Edge.md

@@ -0,0 +1,47 @@
+---
+tags:
+  - OMSCS
+  - Algorithms
+  - Practice
+  - Alg-Graph
+---
+# 4.12 - Shortest Cycle Containing Edge
+> Give an $O(|V|^2)$ algorithm for the following task.
+> 
+> *Input*: An undirected graph $G=(V,E)$; edge lengths $l_e > 0$; an edge $e \in E$.
+> 
+> *Output:* The length of the shortest cycle containing edge $e$.
+
+## Exploration
+We have some office-hours from course staff, which helps clarify that this question is asking about the minimum cost cycle containing $e$.
+
+The runtime constraint excludes FW and BF. The edge weights exclude BFS and DFS from being the only consideration. That leaves Dijkstra's algorithm, which has runtime $O((n+m) \space log \space n)$.
+
+The fact that this problem involves an undirected graph, makes me think we can post-process the results of Dijkstra from either or both of the vertices which define $e=(u,v)$. The postprocessing step will run longer than Dijkstra's does on its own.
+
+Let's suppose that we run Dijkstra's from $u$, that gives us the distance from $u$ to all other vertices in $G$. We'll call this $dist_u$. From here, we need to find cycles. We can find cycles by looking for 2 vertices reachable from $u$ which can also reach each other.
+
+Ignore all this. Can't we just remove $e$ from $G$, run Dijkstra's from $u$, take the shortest path from $u$ to $v$, then add add $e$ to that path?
+
+Yes, that was the TA's solution.
+
+## Algorithm
+Remove $e=(u,v)$ from $G$, creating $G'$. Run Dijkstra's algorithm from $u$ in $G'$. Find the shortest path $P$ from $u$ to $v$ in $G'$. Adding $e$ to $P$ creates a cycle. In $G$, this cycle will be the shortest cycle in $G$ which contains $e$.
+
+Since we don't need the actual path, just the distance, we can take the distance from $u$ to $v$ in $G'$ and add $w(e)$ to produce the required answer.
+
+## Justification
+We know that $e=(u,v) \in E$ exists within a cycle in $G$. That means there exists at least 2 paths from $u$ to $v$ in G. One path is simply $(u, v)$. The other paths don't use $e$. If we remove $e$ from $G$, we can find the shortest of those alternative paths. Adding $e$ onto that path results in the shortest cycle in $G$ which contains $e$.
+
+## Runtime
+- Copying G without $e$: $O(n+m)$
+	- The alternative is to remove $e$ in $G$ and then fix $G$ later. That cost is $O(n)$ for the removal, and $O(n)$ for the re-addition later.
+- Running Dijkstra's in $G'$: $O((n+m) log (n))$
+- Finding the cost of the minimum uv-path in $G'$: $O(1)$
+- Adding $w(e)$ to that cost: $O(1)$
+
+Overall, running Dijkstra's algorithm dominates the runtime.
+
+$O((n+m) \space log \space n)$
+
+This doesn't necessarily beat the required runtime of $O(n^2)$. In fact, it's worse.

OMSCS/Courses/GA/Practice Problems/4.13 - Set of Cities.md

@@ -0,0 +1,37 @@
+---
+tags:
+  - OMSCS
+  - Algorithms
+  - Practice
+  - Alg-Graph
+---
+# 4.13 - Set of Cities
+![[Pasted image 20260315153327.png]]
+
+## Part A
+### Algorithm
+Make a new graph $G'$, adding all of the vertices of $G$. For each edge in $G$, only add it to $G'$ if $l_e$ is less than $L$. Run BFS from $s$ in $G'$. If $t$ is reachable from $s$, then there exists a feasible route in $G$.
+### Justification
+By modifying the graph to only contain edges traversable by your vehicle, we can do a simple reachability analysis from $s$ to $t$ in $G'$ to determine whether the prompt is satisfiable.
+### Runtime
+- Creating $G':$ $O(n+m)$
+- Running BFS on $G'$: $O(n+m)$
+- Checking `dist[t]`: $O(1)$
+
+Overall: $O(n+m)$
+
+## Part B
+### Algorithm
+Use Kruskal's to create the minimum spanning tree (MST) of $G$. Run DFS on the MST to produce a path from $s$ to $t$. Find the maximum edge length in that path. This maximum edge length determines the minimum fuel tank capacity required to travel from $s$ to $t$ in $G$.
+### Justification
+Using the MST of G allows us to create paths through $G$ which have the minimum possible edge cost for traversing cuts of $G$. This minimizes the edge costs for a given path through G from s to t. Taking the maximum edge length of the path from s to t in the MST of G gives you the answer.
+
+Doubling that edge cost would be better, but these are risk-taking travelers.
+### Runtime
+- Kruskal's on G: $O(m \space log \space n)$
+- DFS on MST: $O(n+m)$
+- Iterating over prev to find the minimum edge weight: $O(n)$
+ 
+We don't have information about the connectivity of this graph. Therefore overall: $O(n + (m \space log \space n))$
+
+If we know that the graph is connected, then $O(n) \le O(m)$, and therefore $O(m \space log \space n)$

OMSCS/Courses/GA/Practice Problems/4.14 - Shortest Path through Vertex.md

@@ -37,4 +37,4 @@ Overall Runtime: $O((n+m) \space log \space n)$
 
 > You are given a **strongly connected** directed graph.
 
-Strongly connected means that $m>n$, therefore $O(m)>O(n)$, therefore $O(n+m)=O(m)$. Note again that strongly connected does not equal fully connected, so $m \le n^2$.
+Strongly connected means that $O(m) \ge O(n)$, therefore $O(n+m)=O(m)$. Note again that strongly connected does not equal fully connected, so $m \le n^2$.

OMSCS/Courses/GA/Practice Problems/4.2 - Bellman-Ford Example.md

@@ -0,0 +1,183 @@
+---
+tags:
+  - OMSCS
+  - Algorithms
+  - Practice
+  - Alg-Graph
+---
+# 4.2 - Bellman-Ford Example
+![[Pasted image 20260314160922.png]]
+
+The "previous problem": [[4.1 - Dijkstra Example]]
+## Graph
+```mermaid
+graph LR
+
+S --[6]--> C
+S --[7]--> A
+S --[5]--> F
+S --[6]--> E
+
+A --[-2]--> C
+A --[4]--> B
+
+
+B --[-4]--> H
+B --[-2]--> G
+
+C --[2]--> D
+C --[1]--> F
+
+E --[-2]--> F
+E --[3]--> H
+
+F --[3]--> D
+
+G --[-1]--> I
+H --[1]--> G
+I --[1]--> H
+```
+
+## 4.2a - BF Propagation
+There are 10 vertices, so we need to iterate 9 times. 16 edges by 9 iterations means 144 `update()` operations, where `update()` is defined:
+
+$update((u,v) \in E)$
+	$dist(v)=\min\{dist(v), dist(u)+l(u,v)\}$
+
+We can reduce the amount of updates performed if we exit once no updates are performed in a given iteration.
+
+```python
+E_RAW = """..."""  # The serialized mermaid diagram
+edge_regex = re.compile(r"(\w) --\[(\-?\d+)\]--> (\w)")
+
+E = []
+for line in E_RAW.strip().splitlines():
+    match = edge_regex.match(line)
+    if match:
+        source, weight, target = match.groups()
+        E.append((source, target, int(weight)))
+
+DIST = {**{v: float("inf") for v in V}, "S": 0}
+
+for iteration in range(0, len(V) - 1):
+    update_performed = False
+    for u, v, l_uv in E:
+        if DIST[v] > DIST[u] + l_uv:
+            DIST[v] = DIST[u] + l_uv
+            update_performed = True
+
+    if not update_performed:
+        break
+```
+
+By injecting some print statements into this procedure, we can extract the updates performed to the DIST table, to show how it evolves over time. There are no updates performed during iteration 3, so the last update made during iteration 2 represents the output of the table.
+
+| iter. | Edge       | S   | A       | B        | C       | D       | E       | F       | G       | H       | I       |
+| ----- | ---------- | --- | ------- | -------- | ------- | ------- | ------- | ------- | ------- | ------- | ------- |
+| t=0   | `nil`      | 0   | inf     | inf      | inf     | inf     | inf     | inf     | inf     | inf     | inf     |
+| t=1   | $\vec{SC}$ | 0   | inf     | inf      | **-6-** | inf     | inf     | inf     | inf     | inf     | inf     |
+| t=1   | $\vec{SA}$ | 0   | **-7-** | inf      | 6       | inf     | inf     | inf     | inf     | inf     | inf     |
+| t=1   | $\vec{SF}$ | 0   | 7       | inf      | 6       | inf     | inf     | **-5-** | inf     | inf     | inf     |
+| t=1   | $\vec{SE}$ | 0   | 7       | inf      | 6       | inf     | **-6-** | 5       | inf     | inf     | inf     |
+| t=1   | $\vec{AC}$ | 0   | 7       | inf      | **-5-** | inf     | 6       | 5       | inf     | inf     | inf     |
+| t=1   | $\vec{AB}$ | 0   | 7       | **-11-** | 5       | inf     | 6       | 5       | inf     | inf     | inf     |
+| t=1   | $\vec{BH}$ | 0   | 7       | 11       | 5       | inf     | 6       | 5       | inf     | **-7-** | inf     |
+| t=1   | $\vec{BG}$ | 0   | 7       | 11       | 5       | inf     | 6       | 5       | **-9-** | 7       | inf     |
+| t=1   | $\vec{CD}$ | 0   | 7       | 11       | 5       | **-7-** | 6       | 5       | 9       | 7       | inf     |
+| t=1   | $\vec{EF}$ | 0   | 7       | 11       | 5       | 7       | 6       | **-4-** | 9       | 7       | inf     |
+| t=1   | $\vec{GI}$ | 0   | 7       | 11       | 5       | 7       | 6       | 4       | 9       | 7       | **-8-** |
+| t=1   | $\vec{HG}$ | 0   | 7       | 11       | 5       | 7       | 6       | 4       | **-8-** | 7       | 8       |
+| t=2   | $\vec{GI}$ | 0   | 7       | 11       | 5       | 7       | 6       | 4       | 8       | 7       | **-7-** |
+
+## 4.2b - SP Tree
+
+The BF algorithm also iteratively keeps track of a $prev[]$ vector, building a tree. However, we canalso  reconstruct this tree from the $dist[]$ vector. Starting from S in the table, we can build the SP Tree by checking the edges out of S ($(S,v) \in E$) to see if the distance from S to $v$ matches what's in the table. Here's the final resulting row of the $dist()$ array.
+
+| S   | A   | B   | C   | D   | E   | F   | G   | H   | I   |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| 0   | 7   | 11  | 5   | 7   | 6   | 4   | 8   | 7   | 7   |
+
+For the edges leaving S
+- $l(\vec{SC}) = 6 \ne dist(C)$
+- $l(\vec{SA}) =7 = dist(A)$
+- $l(\vec{SF}) = 5 \ne dist(F)$
+- $l(\vec{SE}) = 6 = dist(E)$
+
+This leaves us with this tree so far.
+
+```mermaid
+graph LR
+
+S --[7]--> A
+S --[6]--> E
+```
+
+Now we can check the edges leaving A and E.
+- For the edges leaving A ($dist(A)=7$)
+	- $7+l(\vec{AC})=7-2=5=dist(C)$
+	- $7 + l(\vec{AB})=7+4=11=dist(B)$
+- For the edges leaving E ($dist(E)=6$)
+	- $6 + l(\vec{EF}) = 6 - 2 = 4 = dist(F)$
+	- $6 + l(\vec{EH}) = 6 + 3 = 9 \ne dist(H)$
+
+We can add C, B, and F to the tree.
+
+```mermaid
+graph LR
+
+S --[7]--> A
+S --[6]--> E
+
+A --[-2]--> C
+A --[4]--> B
+E --[-2]--> F
+```
+
+Now we can check the edges leaving C, B, and F
+- For the edges leaving C ($dist(C)=5$)
+	- $5 + l(\vec{CD}) = 5 + 2 = 7 = dist(D)$
+	- $\vec{CF}:$ F is already in the tree.
+- For the edges leaving B ($dist(B)=11$)
+	- $11 + l(\vec{BH}) = 11 - 4 = 7 = dist(H)$
+	- $11 + l(\vec{BG}) = 11 - 2 = 9 \ne dist(G)$
+- For the edges leaving F ($dist(F)=4$)
+	- $4+l(\vec{FD})=4+3=7=dist(D)$
+
+We can now add D and H to the tree, though we arrived at D 2 ways. We'll pick $(S,A,C,D)$ instead of $(S,E,F,D)$, because of node order. This demonstrates the importance of relying on the `prev[]` array instead of trying to rebuild the tree from `dist[]`.
+
+```mermaid
+graph LR
+
+S --[7]--> A
+S --[6]--> E
+
+A --[-2]--> C
+A --[4]--> B
+E --[-2]--> F
+
+C --[2]--> D
+B --[-4]--> H
+```
+
+We can check the edge leaving H now, though there's only 1.
+- $dist(H)=7$
+- $7+l(\vec{HG})=7+1=8=dist(G)$
+
+We can also shortcut the last step, because only $\vec{GI}$ reaches I. Walking through the tree from S to all vertices and keeping track of the distances successfully reconstructs the `dist[]` table.
+
+```mermaid
+graph LR
+
+S --[7]--> A
+S --[6]--> E
+
+A --[-2]--> C
+A --[4]--> B
+E --[-2]--> F
+
+C --[2]--> D
+B --[-4]--> H
+
+H --[1]--> G
+G --[-1]--> I
+```