Class 51: Reachability

Held Wednesday, May 5

Summary

• Reachability: can you get there from here?

Contents

Notes

• Because of confusion as to when information had to be in to dining services, the picnic will be rescheduled (probably for Friday, May 14) (presumably at the end of the day).
  • If you want to remove your name from the signup list, that's fine.
• Are there questions on exam 3?
• I was dismayed by the latecomers and late attendance yesterday. Please make sure to make it to class, and to make it to class on time.

Project Discussions

• We will use the first fifteen minutes of class for project discussions. If you have comments or questions, let's talk about them (or at least enumerate them).
• One that I've noticed is that no one has included the listField method. However, since the database doesn't rely on it, it's not a big problem.

Reachability Analysis

• Reachability is perhaps the simplest graph algorithm. Starting at one node in a graph (directed or undirected), determine if you can reach another node in that graph (or how many steps it takes).
• Note that this is, in effect, a variant of the theory behind the legendary ``six degrees of Kevin Bacon'' game.
  • That is, Kevin Bacon can be reached from any actor (in six steps or less).
• We might begin by a ``mathematical'' (perhaps just formal) definition of reachability. B is reachable from A if
  • B is the same node as A.
  • There is an edge from A to B (between A and B).
  • There exists a node, C, such that C is reachable from A and B is reachable from C.
• We can simplify this slightly. B is reachable from A if
  • B is the same node as A.
  • There is an edge from A to C and B is reachable from C.
• (How might you prove these equivalent?)
• Note that we can turn this definition into an algorithm.

  static boolean pathBetween(GraphNode source, GraphNode destination) {
    // Base case
    if (source.equals(destination)) return true;
    // Recursive case: see if there's a path from 
    // a neighbor to the destination.
    for each neighbor of source {
      if pathBetween(neighbor,destination) return true;
    }
    // If we reach this point, we've effectively tried every 
    // possible way to reach the destination.  It must not
    // be possible.
    return false;
  } // reachable
  

• A problem with this algorithm is that there may be an edge back to A, so we may end up revisiting A without ever finding a solution.
• Consider

     +----+
     |    ^
     v    |
     A -> C -> D -> B
  

• How might our algorithm progress?

  Is there a path from A to B?
   Is B equal to A?  No.
   Pick some neighbor of A.  C is the only one.
   Is there a path from C to B?
     Is B equal to C?  No.
     Pick some neighbor of C.  Let's pick A.
     Is there a path from A to B?
       Is B equal to A?  No.
       Pick some neighbor of A.  C is the only one.
       Is there a path form C to B?
        ...
  

• How do we fix this problem? By keeping track of which nodes we've visited.

  static boolean pathBetween(GraphNode source, GraphNode destination) {
    // Note that we've seen the source.
    mark(source);
    // Base case: we're already there.
    if (source.equals(destination)) return true;
    // Recursive case: try all the neighbors.
    foreach neighbor of source
      if (!marked(neighbor) && pathBetween(neighbor,destination)) return true;
    }
    // Tried everything.  Give up.
    return false;
  } // reachable
  

• This gives a ``depth-first'' search of the tree.
• We may try this algorithm on a few larger examples.

Shortest Path

• The shortest path algorithm finds the shortest path from A to B in a graph. The shortest path from A to B is a path from A to B whose cost (determined by some cost function) is no greater than any other path from A to B.
• The algorithm generally applies to directed, weighted graphs.
• The cost function is most often the sum of the weights of the edges on the path, but it might involve other combinations, such as
  • the average of the weights
  • the product of the weights
  • some function of weights and number of edges
  • ...
• Typically, the weights on the graph are nonnegative.
  • If the graph includes negative weights and cycles, there may be no shortest path, as there may be a cycle which decreases the cost each time it is taken.
• Depending on the algorithm we develop, there may also be other restrictions on weights, structure, or cost function to ensure that there is a clear shortest path.

A Brute-Force Solution

• In general, shortest paths don't involve cycles. If we can guarantee that this is the case (e.g., if all weights are positive), then there is a very simple method for finding shortest path.
  • List all acyclic paths.
  • Compute the cost of each path.
  • Pick the smallest such cost.
• This guarantees that we get a correct answer. Why? Because it explicitly matches the definition of shortest path.
• Are there disadvantages? Possibly.
• What is the running time of this algortihm?
  • It is clearly proportional to the number of paths in the graph times the cost of determing the cost of each path.
  • So, how many distinct paths are there in a graph? What does it depend on?
  • Note that for graph algorithms, we tend to use n for the number of nodes in the graph and m for the number of edges.

History

• Created Monday, January 11, 1999.
• Added short summary on Friday, January 22, 1999.
• Filled in details on Tuesday, May 4, 1999. Many were based on outline 49 of CS152 98S