Sei sulla pagina 1di 8

# GRAPHS

## Abstraction is one of the key ideas in software engineering.

Rather than building multiple different pieces of code to
store a list of numbers, a list of names, a list of DNA
sequences, etc., we simply build one single piece of code
representing “a list of objects,” then use that list to store
data of all different types.
In this chapter, we will introduce a powerful abstraction
that will appear repeatedly throughout our explo- ration of
the mathematical foundations of computing: the graph.
Graphs make it possible to reason about the relations
between objects and how individual connections between
objects can give rise to larger struc- tures. For example,
studying graphs makes it possible to reason about the
overall distances between two cities, given their pairwise
distances, or to find an optimal allocation of workers to
tasks, given information on each individual worker's
preferences.
Intuitively, a graph is a collection of objects (usually
referred to as nodes or vertices) that can be connected to
one another. Specifically, any pair of nodes may be
connected by an edge (sometimes called an arc). Here are
some examples of graphs:• Molecules in chemistry can be
thought of as graphs – each atom in the molecule is a node,
and each bond between two atoms is an edge.
• Social networks like Facebook are graphs – each person is
a node, and each friendship between two people is an edge.
• The Internet is a graph. Each computer is a node, and
there is an edge between two computers if the first
computer can directly communicate with the second.
• Polyhedra like cubes, pyramids, and dodecahedrons are
graphs. Each corner of the polyhedron is a vertex, and there
is an edge between vertices if there is an edge of the solid
connecting them.
• Highway systems are graphs. Each node represents a
place where two highways meet, and there are edges
between two connections if the junctions have a highway
between them.

## Your brain is a graph. Each neuron is a node, and there are

edges between neurons if they meet at a synapse.

## Ordered and Unordered Pairs

In order to discuss graphs, we need a way of formalizing
what a node and edge are. Typically, anything can act as
nodes in a graph: people, places, words, numbers, neurons,
etc. Since edges run between two nodes, we often represent
edges as which pair of nodes they connect. For example, if
we have a graph where each node is a person and each edge
represents a friendship, we would represent the edge
indicating that Alice is friends with Bob with the pair
“Alice, Bob.”
An unordered pair is a set { a, b } representing the two
objects a and b
Intuitively, an unordered pair represents two objects without
specifying that one of these objects is the “first” object and
that one of these is the “second” object. For example, the
friendship between Alice and Bob might be represented as
the unordered pair { Alice, Bob }. Since sets are unordered
collections of distinct elements, this means that { Alice,
Bob } = { Bob, Alice }.In some cases, we might have that a
node in a graph is connected to itself. For example, let's
consider a graph where each node represents a computer on
a network and each edge between computers represents a
pair of computers that can directly communicate with one
another. Each computer is capable of communi- cating with
itself, and so each computer would have an edge to itself.
For example, HAL9000 would be connected to HAL9000,
represent these connec- tions with the unordered pairs
you'll remember, sets are unordered collections of distinct
elements, which means that the set { HAL9000,
HAL9000 } is the exact same set as { HAL9000 }.
However, we will still consider this singleton set to be an
unordered pair. Specifically, any set { a } can be thought of
as an unordered pair containing two copies of a.

## Unordered pairs are useful if we want to pair up objects

together such that neither is “first” or “second.” However,
in some cases we may want to have two objects where there
is a clear “first” and “second.” For example, suppose that
we have a graph where each node represents a type of food.
Some types of food are tastier than others. If one type of
food is tastier than another, then we will represent this by
drawing an edge from the tastier food to the less tasty food.
For example, if I rank food according to my preferences,
we would get this graph:
An unordered pair is a set { a, b } representing the two
objects a and b.
An ordered pair is a collection of two objects a and b in
order. We denote the ordered pair consist-
ingfirstofa,thenofbas(a,b).
Twoorderedpairs(a0,b0)and(a1,b1)areequalifa0 =a1
andb0 = b1.

## For example, I would represent that I like Italian more than

fast food with the ordered pair (Italian, Fast Food).
Similarly, I would represent that I like Thai more than
American with the ordered pair (Thai, Amer- ican).*

## A Formal Definition of Graphs

Now that we have a formal definition of nodes and edges,
we can formally define a graph.
This definition of a graph is very flexible, and we can use
whatever objects we'd like as the vertices.

Navigating a Graph
We have defined a graph as simply a set of objects that act
as nodes and a set of edges linking individual pairs of
nodes. However, most of the interesting operations on
graphs, and many of the applications best modeled by
graphs, focus on the interactions between multiple nodes
and multiple edges. In fact, the entire remainder of this
chapter explores properties of graphs that are too global to
be understood simply by look- ing at a single node or a
single edge.
To start off, let's consider the following graph, which shows
the Eisenhower freeway system and how it con- nects
various cities:

Some pairs of cities are directly connected to one another
by highways. For example, there is a direct con­ nection
from San Francisco to Sacramento, and from Sacramento to
Los Angeles. However, other pairs of cities are connected
by the highway system, but not directly connected. For
example, it's possible to reach Chicago from San Francisco
by going from San Francisco to Sacramento, Sacramento to
Salt Lake City, Salt Lake City to Cheyenne, Cheyenne to
Omaha, Omaha to Des Moines, and finally from Des
Moines to Chicago.
This sequence of cities – San Francisco, Sacramento, Salt
Lake City, Cheyenne, Omaha, Des Moines – rep­ resents a
way of getting from one city to another along a series of
hops, rather than just a single hop. We can generalize this to
a larger setting: given an arbitrary graph G = (V, E), is it
possible to get from one node s to another node t by
following a series of edges? If the nodes are directly
connected, we can just follow the edge between them, but
otherwise we might have to take a longer series of edges to
arrive at the destina­ tion.
We can formalize this idea here:
In other words, a path is a series of nodes where each
adjacent pair of nodes has an edge connecting them. It's
legal to have a path consisting of any nonzero number of
nodes. The above path in the highway graph has six nodes
in it. We can consider a short path of just two nodes, such
as the path from New York to Phil­ adelphia, or even a
trivial path of just one node from any city to itself.

The above definition of a path only says that any adjacent
pair of nodes must have an edge connecting them. This
means that, according to our definition, the following is a
legal path from San Francisco to Los Ange­ les:
(SF, LA, SF, LA, SF, LA, SF, LA)
This is a very silly path, since it just keeps going around
and around and around. In many cases when we discuss
paths in a graph, we want to disallow paths that repeatedly
revisit the same locations over and over again. This gives
rise to the definition of a simple path:
Under this definition, the path (SF, LA, SF, LA) is indeed a
legal path, but it is not a simple path. The initial path we
took from San Francisco to Chicago is also simple path.
Notice that this definition just says that a simple path
cannot repeat any nodes. This implicitly also means that the
path cannot repeat any edges, since if that were the case the
path would have to repeat that edge's endpoints.
The notion of a path gives us a way of formalizing a trip
from one city to another. Now, let's suppose that we want to
take a short vacation from some city (say, Knoxville). This
means that we want to leave Knoxville, go visit a few other
cities, and then ultimately return back to Knoxville. For
example, one possi­ ble trip would be to go from Knoxville
to Nashville, from there to Birmingham, then to Atlanta,
then to Charlotte, Winston­Salem, and then back to
Knoxville. We could describe this trip as a path from
Knoxville back to itself:
(Knoxville, Nashville, Birmingham, Atlanta, Charlotte,
Winston­Salem, Knoxville)
This path is not a simple path, because Knoxville appears
twice. However, it is an important type of path, in
that it starts and ends at the same location. We call such a
path a cycle:
As with our definition of a path, notice that this definition
of cycle says nothing about what nodes are along the path,
as long as we start and end at the same node. Sometimes,
we want to talk about cycles that, in a spirit similar to that
of simple paths, don't end up repeating themselves
unnecessarily. That is, we want to consider cycles that start
at a given node, return to that node, and don't end up
retracing any steps or repeat­ ing any other vertices. For
example, we wouldn't want to talk about cycles like this
one:
(SF, LA, Phoenix, LA, SF) which retrace the same edges
multiple times, or this one:
(LA, San Diego, Nogales, Phoenix, Flagstaff, Albuquerque,
El Paso, Phoenix, LA)
which never ends up retracing the same stretch of highway,
but does indeed revisit some intermediate city (in this case,
Phoenix) twice. To distinguish cycles like these, which end
up retracing the same node or edge twice, from “simpler”
cycles that don't retrace any steps, we have this definition:
A simple path is a path with no repeated nodes.
A cycle is a path that starts and ends at the same node.