Add the initial translation for the Graph chapter (#1211)

This commit is contained in:
Yudong Jin 2024-04-02 18:52:34 +08:00 committed by GitHub
parent 04ebee0308
commit 06068927cd
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
46 changed files with 352 additions and 7 deletions

Binary file not shown.

After

Width:  |  Height:  |  Size: 18 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 19 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 11 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 13 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 20 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 14 KiB

View file

@ -0,0 +1,83 @@
# Graph
A "graph" is a type of nonlinear data structure, consisting of "vertices" and "edges". A graph $G$ can be abstractly represented as a collection of a set of vertices $V$ and a set of edges $E$. The following example shows a graph containing 5 vertices and 7 edges.
$$
\begin{aligned}
V & = \{ 1, 2, 3, 4, 5 \} \newline
E & = \{ (1,2), (1,3), (1,5), (2,3), (2,4), (2,5), (4,5) \} \newline
G & = \{ V, E \} \newline
\end{aligned}
$$
If vertices are viewed as nodes and edges as references (pointers) connecting the nodes, graphs can be seen as a data structure that extends from linked lists. As shown below, **compared to linear relationships (linked lists) and divide-and-conquer relationships (trees), network relationships (graphs) are more complex due to their higher degree of freedom**.
![Relationship between linked lists, trees, and graphs](graph.assets/linkedlist_tree_graph.png)
## Common types of graphs
Based on whether edges have direction, graphs can be divided into "undirected graphs" and "directed graphs", as shown below.
- In undirected graphs, edges represent a "bidirectional" connection between two vertices, for example, the "friendship" in WeChat or QQ.
- In directed graphs, edges have directionality, that is, the edges $A \rightarrow B$ and $A \leftarrow B$ are independent of each other, for example, the "follow" and "be followed" relationship on Weibo or TikTok.
![Directed and undirected graphs](graph.assets/directed_graph.png)
Based on whether all vertices are connected, graphs can be divided into "connected graphs" and "disconnected graphs", as shown below.
- For connected graphs, it is possible to reach any other vertex starting from a certain vertex.
- For disconnected graphs, there is at least one vertex that cannot be reached from a certain starting vertex.
![Connected and disconnected graphs](graph.assets/connected_graph.png)
We can also add a "weight" variable to edges, resulting in "weighted graphs" as shown below. For example, in mobile games like "Honor of Kings", the system calculates the "closeness" between players based on shared gaming time, and this closeness network can be represented with a weighted graph.
![Weighted and unweighted graphs](graph.assets/weighted_graph.png)
Graph data structures include the following commonly used terms.
- "Adjacency": When there is an edge connecting two vertices, these two vertices are said to be "adjacent". In the above figure, the adjacent vertices of vertex 1 are vertices 2, 3, and 5.
- "Path": The sequence of edges passed from vertex A to vertex B is called a "path" from A to B. In the above figure, the edge sequence 1-5-2-4 is a path from vertex 1 to vertex 4.
- "Degree": The number of edges a vertex has. For directed graphs, "in-degree" refers to how many edges point to the vertex, and "out-degree" refers to how many edges point out from the vertex.
## Representation of graphs
Common representations of graphs include "adjacency matrices" and "adjacency lists". The following examples use undirected graphs.
### Adjacency matrix
Let the number of vertices in the graph be $n$, the "adjacency matrix" uses an $n \times n$ matrix to represent the graph, where each row (column) represents a vertex, and the matrix elements represent edges, with $1$ or $0$ indicating whether there is an edge between two vertices.
As shown below, let the adjacency matrix be $M$, and the list of vertices be $V$, then the matrix element $M[i, j] = 1$ indicates there is an edge between vertex $V[i]$ and vertex $V[j]$, conversely $M[i, j] = 0$ indicates there is no edge between the two vertices.
![Representation of a graph with an adjacency matrix](graph.assets/adjacency_matrix.png)
Adjacency matrices have the following characteristics.
- A vertex cannot be connected to itself, so the elements on the main diagonal of the adjacency matrix are meaningless.
- For undirected graphs, edges in both directions are equivalent, thus the adjacency matrix is symmetric about the main diagonal.
- By replacing the elements of the adjacency matrix from $1$ and $0$ to weights, it can represent weighted graphs.
When representing graphs with adjacency matrices, it is possible to directly access matrix elements to obtain edges, thus operations of addition, deletion, lookup, and modification are very efficient, all with a time complexity of $O(1)$. However, the space complexity of the matrix is $O(n^2)$, which consumes more memory.
### Adjacency list
The "adjacency list" uses $n$ linked lists to represent the graph, with each linked list node representing a vertex. The $i$-th linked list corresponds to vertex $i$ and contains all adjacent vertices (vertices connected to that vertex). The figure below shows an example of a graph stored using an adjacency list.
![Representation of a graph with an adjacency list](graph.assets/adjacency_list.png)
The adjacency list only stores actual edges, and the total number of edges is often much less than $n^2$, making it more space-efficient. However, finding edges in the adjacency list requires traversing the linked list, so its time efficiency is not as good as that of the adjacency matrix.
Observing the above figure, **the structure of the adjacency list is very similar to the "chaining" in hash tables, hence we can use similar methods to optimize efficiency**. For example, when the linked list is long, it can be transformed into an AVL tree or red-black tree, thus optimizing the time efficiency from $O(n)$ to $O(\log n)$; the linked list can also be transformed into a hash table, thus reducing the time complexity to $O(1)$.
## Common applications of graphs
As shown in the table below, many real-world systems can be modeled with graphs, and corresponding problems can be reduced to graph computing problems.
<p align="center"> Table <id> &nbsp; Common graphs in real life </p>
| | Vertices | Edges | Graph Computing Problem |
| --------------- | ---------------- | --------------------------------------------- | -------------------------------- |
| Social Networks | Users | Friendships | Potential Friend Recommendations |
| Subway Lines | Stations | Connectivity Between Stations | Shortest Route Recommendations |
| Solar System | Celestial Bodies | Gravitational Forces Between Celestial Bodies | Planetary Orbit Calculations |

Binary file not shown.

After

Width:  |  Height:  |  Size: 19 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 20 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 20 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 21 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 18 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 17 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 18 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 18 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 22 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 18 KiB

View file

@ -0,0 +1,86 @@
# Basic operations on graphs
The basic operations on graphs can be divided into operations on "edges" and operations on "vertices". Under the two representation methods of "adjacency matrix" and "adjacency list", the implementation methods are different.
## Implementation based on adjacency matrix
Given an undirected graph with $n$ vertices, the various operations are implemented as shown in the figure below.
- **Adding or removing an edge**: Directly modify the specified edge in the adjacency matrix, using $O(1)$ time. Since it is an undirected graph, it is necessary to update the edges in both directions simultaneously.
- **Adding a vertex**: Add a row and a column at the end of the adjacency matrix and fill them all with $0$s, using $O(n)$ time.
- **Removing a vertex**: Delete a row and a column in the adjacency matrix. The worst case is when the first row and column are removed, requiring $(n-1)^2$ elements to be "moved up and to the left", thus using $O(n^2)$ time.
- **Initialization**: Pass in $n$ vertices, initialize a vertex list `vertices` of length $n$, using $O(n)$ time; initialize an $n \times n$ size adjacency matrix `adjMat`, using $O(n^2)$ time.
=== "Initialize adjacency matrix"
![Initialization, adding and removing edges, adding and removing vertices in adjacency matrix](graph_operations.assets/adjacency_matrix_step1_initialization.png)
=== "Add an edge"
![adjacency_matrix_add_edge](graph_operations.assets/adjacency_matrix_step2_add_edge.png)
=== "Remove an edge"
![adjacency_matrix_remove_edge](graph_operations.assets/adjacency_matrix_step3_remove_edge.png)
=== "Add a vertex"
![adjacency_matrix_add_vertex](graph_operations.assets/adjacency_matrix_step4_add_vertex.png)
=== "Remove a vertex"
![adjacency_matrix_remove_vertex](graph_operations.assets/adjacency_matrix_step5_remove_vertex.png)
Below is the implementation code for graphs represented using an adjacency matrix:
```src
[file]{graph_adjacency_matrix}-[class]{graph_adj_mat}-[func]{}
```
## Implementation based on adjacency list
Given an undirected graph with a total of $n$ vertices and $m$ edges, the various operations can be implemented as shown in the figure below.
- **Adding an edge**: Simply add the edge at the end of the corresponding vertex's linked list, using $O(1)$ time. Because it is an undirected graph, it is necessary to add edges in both directions simultaneously.
- **Removing an edge**: Find and remove the specified edge in the corresponding vertex's linked list, using $O(m)$ time. In an undirected graph, it is necessary to remove edges in both directions simultaneously.
- **Adding a vertex**: Add a linked list in the adjacency list and make the new vertex the head node of the list, using $O(1)$ time.
- **Removing a vertex**: It is necessary to traverse the entire adjacency list, removing all edges that include the specified vertex, using $O(n + m)$ time.
- **Initialization**: Create $n$ vertices and $2m$ edges in the adjacency list, using $O(n + m)$ time.
=== "Initialize adjacency list"
![Initialization, adding and removing edges, adding and removing vertices in adjacency list](graph_operations.assets/adjacency_list_step1_initialization.png)
=== "Add an edge"
![adjacency_list_add_edge](graph_operations.assets/adjacency_list_step2_add_edge.png)
=== "Remove an edge"
![adjacency_list_remove_edge](graph_operations.assets/adjacency_list_step3_remove_edge.png)
=== "Add a vertex"
![adjacency_list_add_vertex](graph_operations.assets/adjacency_list_step4_add_vertex.png)
=== "Remove a vertex"
![adjacency_list_remove_vertex](graph_operations.assets/adjacency_list_step5_remove_vertex.png)
Below is the adjacency list code implementation. Compared to the above diagram, the actual code has the following differences.
- For convenience in adding and removing vertices, and to simplify the code, we use lists (dynamic arrays) instead of linked lists.
- Use a hash table to store the adjacency list, `key` being the vertex instance, `value` being the list (linked list) of adjacent vertices of that vertex.
Additionally, we use the `Vertex` class to represent vertices in the adjacency list. The reason for this is: if, like with the adjacency matrix, list indexes were used to distinguish different vertices, then suppose you want to delete the vertex at index $i$, you would need to traverse the entire adjacency list and decrement all indexes greater than $i$ by $1$, which is very inefficient. However, if each vertex is a unique `Vertex` instance, then deleting a vertex does not require any changes to other vertices.
```src
[file]{graph_adjacency_list}-[class]{graph_adj_list}-[func]{}
```
## Efficiency comparison
Assuming there are $n$ vertices and $m$ edges in the graph, the table below compares the time efficiency and space efficiency of the adjacency matrix and adjacency list.
<p align="center"> Table <id> &nbsp; Comparison of adjacency matrix and adjacency list </p>
| | Adjacency matrix | Adjacency list (Linked list) | Adjacency list (Hash table) |
| ------------------- | ---------------- | ---------------------------- | --------------------------- |
| Determine adjacency | $O(1)$ | $O(m)$ | $O(1)$ |
| Add an edge | $O(1)$ | $O(1)$ | $O(1)$ |
| Remove an edge | $O(1)$ | $O(m)$ | $O(1)$ |
| Add a vertex | $O(n)$ | $O(1)$ | $O(1)$ |
| Remove a vertex | $O(n^2)$ | $O(n + m)$ | $O(n)$ |
| Memory space usage | $O(n^2)$ | $O(n + m)$ | $O(n + m)$ |
Observing the table above, it seems that the adjacency list (hash table) has the best time efficiency and space efficiency. However, in practice, operating on edges in the adjacency matrix is more efficient, requiring only a single array access or assignment operation. Overall, the adjacency matrix exemplifies the principle of "space for time", while the adjacency list exemplifies "time for space".

Binary file not shown.

After

Width:  |  Height:  |  Size: 23 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 19 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 36 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 27 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 30 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 32 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 33 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 35 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 35 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 35 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 36 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 36 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 25 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 16 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 28 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 33 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 20 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 22 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 22 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 23 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 25 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 24 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 27 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 32 KiB

View file

@ -0,0 +1,136 @@
# Graph traversal
Trees represent a "one-to-many" relationship, while graphs have a higher degree of freedom and can represent any "many-to-many" relationship. Therefore, we can consider trees as a special case of graphs. Clearly, **tree traversal operations are also a special case of graph traversal operations**.
Both graphs and trees require the application of search algorithms to implement traversal operations. Graph traversal can be divided into two types: "Breadth-First Search (BFS)" and "Depth-First Search (DFS)".
## Breadth-first search
**Breadth-first search is a near-to-far traversal method, starting from a certain node, always prioritizing the visit to the nearest vertices and expanding outwards layer by layer**. As shown in the figure below, starting from the top left vertex, first traverse all adjacent vertices of that vertex, then traverse all adjacent vertices of the next vertex, and so on, until all vertices have been visited.
![Breadth-first traversal of a graph](graph_traversal.assets/graph_bfs.png)
### Algorithm implementation
BFS is usually implemented with the help of a queue, as shown in the code below. The queue has a "first in, first out" property, which aligns with the BFS idea of traversing "from near to far".
1. Add the starting vertex `startVet` to the queue and start the loop.
2. In each iteration of the loop, pop the vertex at the front of the queue and record it as visited, then add all adjacent vertices of that vertex to the back of the queue.
3. Repeat step `2.` until all vertices have been visited.
To prevent revisiting vertices, we use a hash table `visited` to record which nodes have been visited.
```src
[file]{graph_bfs}-[class]{}-[func]{graph_bfs}
```
The code is relatively abstract, it is suggested to compare with the following figure to deepen the understanding.
=== "<1>"
![Steps of breadth-first search of a graph](graph_traversal.assets/graph_bfs_step1.png)
=== "<2>"
![graph_bfs_step2](graph_traversal.assets/graph_bfs_step2.png)
=== "<3>"
![graph_bfs_step3](graph_traversal.assets/graph_bfs_step3.png)
=== "<4>"
![graph_bfs_step4](graph_traversal.assets/graph_bfs_step4.png)
=== "<5>"
![graph_bfs_step5](graph_traversal.assets/graph_bfs_step5.png)
=== "<6>"
![graph_bfs_step6](graph_traversal.assets/graph_bfs_step6.png)
=== "<7>"
![graph_bfs_step7](graph_traversal.assets/graph_bfs_step7.png)
=== "<8>"
![graph_bfs_step8](graph_traversal.assets/graph_bfs_step8.png)
=== "<9>"
![graph_bfs_step9](graph_traversal.assets/graph_bfs_step9.png)
=== "<10>"
![graph_bfs_step10](graph_traversal.assets/graph_bfs_step10.png)
=== "<11>"
![graph_bfs_step11](graph_traversal.assets/graph_bfs_step11.png)
!!! question "Is the sequence of breadth-first traversal unique?"
Not unique. Breadth-first traversal only requires traversing in a "from near to far" order, **and the traversal order of multiple vertices at the same distance can be arbitrarily shuffled**. For example, in the above figure, the visitation order of vertices $1$ and $3$ can be switched, as can the order of vertices $2$, $4$, and $6$.
### Complexity analysis
**Time complexity**: All vertices will be enqueued and dequeued once, using $O(|V|)$ time; in the process of traversing adjacent vertices, since it is an undirected graph, all edges will be visited $2$ times, using $O(2|E|)$ time; overall using $O(|V| + |E|)$ time.
**Space complexity**: The maximum number of vertices in list `res`, hash table `visited`, and queue `que` is $|V|$, using $O(|V|)$ space.
## Depth-first search
**Depth-first search is a traversal method that prioritizes going as far as possible and then backtracks when no further paths are available**. As shown in the figure below, starting from the top left vertex, visit some adjacent vertex of the current vertex until no further path is available, then return and continue until all vertices are traversed.
![Depth-first traversal of a graph](graph_traversal.assets/graph_dfs.png)
### Algorithm implementation
This "go as far as possible and then return" algorithm paradigm is usually implemented based on recursion. Similar to breadth-first search, in depth-first search, we also need the help of a hash table `visited` to record the visited vertices to avoid revisiting.
```src
[file]{graph_dfs}-[class]{}-[func]{graph_dfs}
```
The algorithm process of depth-first search is shown in the following figure.
- **Dashed lines represent downward recursion**, indicating that a new recursive method has been initiated to visit a new vertex.
- **Curved dashed lines represent upward backtracking**, indicating that this recursive method has returned to the position where this method was initiated.
To deepen the understanding, it is suggested to combine the following figure with the code to simulate (or draw) the entire DFS process in your mind, including when each recursive method is initiated and when it returns.
=== "<1>"
![Steps of depth-first search of a graph](graph_traversal.assets/graph_dfs_step1.png)
=== "<2>"
![graph_dfs_step2](graph_traversal.assets/graph_dfs_step2.png)
=== "<3>"
![graph_dfs_step3](graph_traversal.assets/graph_dfs_step3.png)
=== "<4>"
![graph_dfs_step4](graph_traversal.assets/graph_dfs_step4.png)
=== "<5>"
![graph_dfs_step5](graph_traversal.assets/graph_dfs_step5.png)
=== "<6>"
![graph_dfs_step6](graph_traversal.assets/graph_dfs_step6.png)
=== "<7>"
![graph_dfs_step7](graph_traversal.assets/graph_dfs_step7.png)
=== "<8>"
![graph_dfs_step8](graph_traversal.assets/graph_dfs_step8.png)
=== "<9>"
![graph_dfs_step9](graph_traversal.assets/graph_dfs_step9.png)
=== "<10>"
![graph_dfs_step10](graph_traversal.assets/graph_dfs_step10.png)
=== "<11>"
![graph_dfs_step11](graph_traversal.assets/graph_dfs_step11.png)
!!! question "Is the sequence of depth-first traversal unique?"
Similar to breadth-first traversal, the order of the depth-first traversal sequence is also not unique. Given a certain vertex, exploring in any direction first is possible, that is, the order of adjacent vertices can be arbitrarily shuffled, all being part of depth-first traversal.
Taking tree traversal as an example, "root $\rightarrow$ left $\rightarrow$ right", "left $\rightarrow$ root $\rightarrow$ right", "left $\rightarrow$ right $\rightarrow$ root" correspond to preorder, inorder, and postorder traversals, respectively. They showcase three types of traversal priorities, yet all three are considered depth-first traversal.
### Complexity analysis
**Time complexity**: All vertices will be visited once, using $O(|V|)$ time; all edges will be visited twice, using $O(2|E|)$ time; overall using $O(|V| + |E|)$ time.
**Space complexity**: The maximum number of vertices in list `res`, hash table `visited` is $|V|$, and the maximum recursion depth is $|V|$, therefore using $O(|V|)$ space.

View file

@ -0,0 +1,9 @@
# Graph
![Graph](../assets/covers/chapter_graph.jpg)
!!! abstract
In the journey of life, we are like individual nodes, connected by countless invisible edges.
Every encountering and parting leaves a unique mark on this vast network graph.

View file

@ -0,0 +1,31 @@
# Summary
### Key review
- A graph consists of vertices and edges and can be represented as a set comprising a group of vertices and a group of edges.
- Compared to linear relationships (linked lists) and divide-and-conquer relationships (trees), network relationships (graphs) have a higher degree of freedom and are therefore more complex.
- The edges of a directed graph have directionality, any vertex in a connected graph is reachable, and each edge in a weighted graph contains a weight variable.
- Adjacency matrices use matrices to represent graphs, with each row (column) representing a vertex and matrix elements representing edges, using $1$ or $0$ to indicate the presence or absence of an edge between two vertices. Adjacency matrices are highly efficient for add, delete, find, and modify operations, but they consume more space.
- Adjacency lists use multiple linked lists to represent graphs, with the $i^{th}$ list corresponding to vertex $i$, containing all its adjacent vertices. Adjacency lists save more space compared to adjacency matrices, but since it is necessary to traverse the list to find edges, their time efficiency is lower.
- When the linked lists in the adjacency list are too long, they can be converted into red-black trees or hash tables to improve query efficiency.
- From the perspective of algorithmic thinking, adjacency matrices embody the principle of "space for time," while adjacency lists embody "time for space."
- Graphs can be used to model various real systems, such as social networks, subway routes, etc.
- A tree is a special case of a graph, and tree traversal is also a special case of graph traversal.
- Breadth-first traversal of a graph is a search method that expands layer by layer from near to far, usually implemented with a queue.
- Depth-first traversal of a graph is a search method that prefers to go as deep as possible and backtracks when no further paths are available, often based on recursion.
### Q & A
**Q**: Is a path defined as a sequence of vertices or a sequence of edges?
Definitions vary between different language versions on Wikipedia: the English version defines a path as "a sequence of edges," while the Chinese version defines it as "a sequence of vertices." Here is the original text from the English version: In graph theory, a path in a graph is a finite or infinite sequence of edges which joins a sequence of vertices.
In this document, a path is considered a sequence of edges, rather than a sequence of vertices. This is because there might be multiple edges connecting two vertices, in which case each edge corresponds to a path.
**Q**: In a disconnected graph, are there points that cannot be traversed to?
In a disconnected graph, starting from a certain vertex, there is at least one vertex that cannot be reached. Traversing a disconnected graph requires setting multiple starting points to traverse all connected components of the graph.
**Q**: In an adjacency list, does the order of "all vertices connected to that vertex" matter?
It can be in any order. However, in practical applications, it might be necessary to sort according to certain rules, such as the order in which vertices are added, or the order of vertex values, etc., to facilitate the quick search for vertices with certain extremal values.

View file

@ -104,13 +104,13 @@ nav:
- 8.2 Building a Heap: chapter_heap/build_heap.md
- 8.3 Top-k Problem: chapter_heap/top_k.md
- 8.4 Summary: chapter_heap/summary.md
# - Chapter 9. Graph:
# # [icon: material/graphql]
# - chapter_graph/index.md
# - 9.1 Graph: chapter_graph/graph.md
# - 9.2 Basic Graph Operations: chapter_graph/graph_operations.md
# - 9.3 Graph Traversal: chapter_graph/graph_traversal.md
# - 9.4 Summary: chapter_graph/summary.md
- Chapter 9. Graph:
# [icon: material/graphql]
- chapter_graph/index.md
- 9.1 Graph: chapter_graph/graph.md
- 9.2 Basic Graph Operations: chapter_graph/graph_operations.md
- 9.3 Graph Traversal: chapter_graph/graph_traversal.md
- 9.4 Summary: chapter_graph/summary.md
# - Chapter 10. Searching:
# # [icon: material/text-search]
# - chapter_searching/index.md