Bird
Raised Fist0
DSA Rustprogramming~5 mins

Graph Terminology Vertices Edges Directed Undirected Weighted in DSA Rust - Time & Space Complexity

Choose your learning style10 modes available
Time Complexity: Graph Terminology Vertices Edges Directed Undirected Weighted
O(E)
Understanding Time Complexity

Graphs are made of points and connections. We want to understand how the size of a graph affects how long it takes to look at its parts.

How does the number of points and connections change the work needed to explore the graph?

Scenario Under Consideration

Analyze the time complexity of the following code snippet.


struct Graph {
    vertices: usize,
    edges: Vec<(usize, usize, Option)>, // (from, to, weight)
}

impl Graph {
    fn count_edges(&self) -> usize {
        let mut count: usize = 0;
        for _ in &self.edges {
            count += 1;
        }
        count
    }
}
    

This code stores a graph with points and connections, some with weights. It counts how many connections exist.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

  • Primary operation: Looping through the edge list to count connections.
  • How many times: The loop executes once per edge.
How Execution Grows With Input

Explain the growth pattern intuitively.

Input Size (number of edges)Approx. Operations
1010
100100
10001000

Pattern observation: The work grows directly with the number of connections. More edges mean more work.

Final Time Complexity

Time Complexity: O(E)

This means the time to check or process edges grows in a straight line with the number of edges.

Common Mistake

[X] Wrong: "The time depends only on the number of points (vertices)."

[OK] Correct: The connections (edges) can be many even if points are few, so time depends on edges too.

Interview Connect

Understanding how vertices and edges affect time helps you explain graph problems clearly and choose the right approach.

Self-Check

"What if the graph was directed instead of undirected? How would the time complexity for counting edges change?"

Practice

(1/5)
1. In graph terminology, what is a vertex?
easy
A. A point or node in the graph where edges meet
B. A line connecting two points in the graph
C. A graph that has no edges
D. A graph with weighted edges

Solution

  1. Step 1: Understand the definition of vertex

    A vertex is a fundamental unit in a graph representing a point or node.
  2. Step 2: Differentiate vertex from edges and graph types

    Edges connect vertices; graphs can be weighted or unweighted, directed or undirected, but vertices are the points themselves.
  3. Final Answer:

    A point or node in the graph where edges meet -> Option A
  4. Quick Check:

    Vertex = point/node [OK]
Hint: Vertices are points, edges are lines connecting them [OK]
Common Mistakes:
  • Confusing vertices with edges
  • Thinking vertex means weighted edge
  • Mixing vertex with graph type
2. Which of the following is the correct Rust syntax to declare an undirected edge between vertices 1 and 2 using a tuple?
easy
A. let edge = {1, 2};
B. let edge = (1, 2);
C. let edge = [1, 2];
D. let edge = <1, 2>;

Solution

  1. Step 1: Recall Rust tuple syntax

    Tuples in Rust are declared with parentheses and comma-separated values, e.g., (1, 2).
  2. Step 2: Check other options for correctness

    Square brackets [] are for arrays, curly braces {} are for blocks or sets (not in Rust), angle brackets <> are not used for tuples.
  3. Final Answer:

    let edge = (1, 2); -> Option B
  4. Quick Check:

    Tuple syntax uses parentheses ( ) [OK]
Hint: Tuples use parentheses ( ), arrays use brackets [ ] [OK]
Common Mistakes:
  • Using square brackets for tuples
  • Using curly braces instead of parentheses
  • Confusing angle brackets with tuple syntax
3. What is the output of the following Rust code that creates a weighted directed edge and prints its components?
struct Edge {
    from: usize,
    to: usize,
    weight: i32,
}

fn main() {
    let e = Edge { from: 3, to: 5, weight: 10 };
    println!("{} -> {} with weight {}", e.from, e.to, e.weight);
}
medium
A. 3 -> 5 with weight 0
B. 5 -> 3 with weight 10
C. 3 -> 5 with weight 10
D. Compilation error due to missing semicolon

Solution

  1. Step 1: Understand struct initialization

    The struct Edge is initialized with from=3, to=5, weight=10 correctly.
  2. Step 2: Analyze the println! macro output

    The print statement outputs the from, to, and weight fields in order: "3 -> 5 with weight 10".
  3. Final Answer:

    3 -> 5 with weight 10 -> Option C
  4. Quick Check:

    Prints from-to-weight as given [OK]
Hint: Struct fields print as assigned, watch order in println! [OK]
Common Mistakes:
  • Swapping from and to values
  • Assuming default weight 0
  • Thinking missing semicolon causes error here
4. Identify the error in this Rust code snippet that tries to create an undirected weighted edge:
struct Edge {
    vertex1: usize,
    vertex2: usize,
    weight: i32,
}

fn main() {
    let e = Edge { vertex1: 1, vertex2: 2 };
    println!("Edge between {} and {} with weight {}", e.vertex1, e.vertex2, e.weight);
}
medium
A. Missing weight field initialization causes a compile error
B. vertex1 and vertex2 should be swapped
C. println! macro syntax is incorrect
D. Edge struct should not have weight for undirected edges

Solution

  1. Step 1: Check struct initialization

    The Edge struct requires vertex1, vertex2, and weight fields. Weight is missing in initialization.
  2. Step 2: Understand Rust's strict initialization rules

    Rust requires all fields to be initialized; missing weight causes compile-time error.
  3. Final Answer:

    Missing weight field initialization causes a compile error -> Option A
  4. Quick Check:

    All struct fields must be initialized [OK]
Hint: All struct fields must be given values when creating instance [OK]
Common Mistakes:
  • Assuming missing fields default to zero
  • Thinking vertex order matters for undirected edges
  • Believing println! syntax is wrong here
5. You want to represent a weighted undirected graph in Rust using an adjacency list. Which data structure is the best choice to store edges with weights efficiently?
hard
A. HashMap storing only vertex connections without weights
B. Vec storing neighbors only, ignoring weights
C. Vec<(usize, usize, i32)> storing all edges as tuples without adjacency
D. Vec> where each inner Vec holds (neighbor_vertex, weight)

Solution

  1. Step 1: Understand adjacency list for weighted graphs

    Weighted graphs need to store neighbors and weights; a Vec of Vec of tuples (neighbor, weight) fits well.
  2. Step 2: Evaluate other options

    HashMap without weights loses weight info; flat Vec of tuples lacks adjacency structure; Vec of usize ignores weights.
  3. Final Answer:

    Vec> where each inner Vec holds (neighbor_vertex, weight) -> Option D
  4. Quick Check:

    Adjacency list with (neighbor, weight) tuples is best [OK]
Hint: Use adjacency list with (neighbor, weight) tuples for weighted graphs [OK]
Common Mistakes:
  • Ignoring weights in adjacency list
  • Using flat edge list without adjacency
  • Using HashMap without weight info
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard