Sei sulla pagina 1di 8


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
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,
and GLaDOS would be connected to GLaDOS. We would
represent these connec- tions with the unordered pairs
{ HAL9000, HAL9000 } and { GLaDOS, GLaDOS }. If
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-
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 
(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.