Search
Now that we have all this new knowledge about representation
in trees, hierarchical structures, networks, and the like, we
need some means for exploring these knowledge structures to
get at the information we want at the time we want it. How
do we do this? The answer is a bunch of techniques which
collectively fall under the heading of "search". Search is a
concept which permeates computer science. We'll only touch
on a couple of kinds of search in this course, but they'll be
sufficient to demonstrate the basic difference between brute-
force, exhaustive, or "dumb" search and heuristic or
"intelligent" search.
Linear search
You probably already know how to do a linear search. You
probably did linear searches in previous programming courses.
For example, starting at the beginning of a file structure
and looking at record after record for a specific entry is a
linear search. (If you've ever seen my office, you know that
the only way I could find something in there is by linear
search: I start at one end of the desk and look at
everything until I find what I'm looking for.) Linear
searches take a long time -- O(n), that kind of time.
(Actually, assuming an even distribution of stuff in the
file, you're looking at 1/2 * O(n), but the constants are
more or less unimportant.)
We can impose a separate indexing scheme on our file
structure, so that we can cut down on some search time. For
example, we could apply a binary search mechanism to look for
an employee record in a file. If the employee's name starts
with a letter in the range A-M, we could start the search at
the beginning of the file, but if the name starts with the
letter N-Z, we would start the search at approximately the
midway point in the file. We could continue to divide the
big groups into smaller groups, until eventually the time to
find a single record is governed not by the behavior of the
linear search but by the behavior of the binary search.
There are other indexing mechanisms that we could use, such
as hashing functions, that would give us different kinds of
advantages.
Searching a hierarchical structure
As we discussed in the previous lecture, we don't always
store our stuff in linear formats. We can also organize
knowledge in hierarchies. Consider, for example, the
Flintstone Family Tree:
Rocky
/ \
/ \
has-mom / \ has-dad
/ \
\/_ _\/
Pebbles Bam-Bam
/ \ has-dad / \
has-mom / \ has-mom / \ has-dad
/ \ / \
\/_ _\/ \/_ _\/
Wilma Fred Betty Barney
In structures like this, as before, we may want to search for
useful information. But structures like this, unlike linear
file structures, make it easier to search for the answers to
questions like "What's the relationship of Barney to Rocky?"
or "Who is Rocky's grandfather on his mother's side?"
Depth-first search
The simplest form of search in a hierarchical or network
structure is called "depth-first search". Here's an
algorithm for depth-first search on a binary tree, looking
for a specific node in the tree:
df-search
1. look at the root
2. if it's what you're looking for, then return success
3. if the root has no descendants, then return failure
4. call df-search on the subtree whose root is the leftmost
descendant and return success if that search is
successful
5. call df-search on the subtree whose root is the rightmost
descendant and return success if that search is
successful
This algorithm may look somewhat familiar, since it's just
a variant of the preorder tree traversal algorithm some of
you have seen in previous courses:
preorder
1. visit the root
2. call preorder on the left subtree
3. call preorder on the right subtree
The big differences between the preorder algorithm and the
depth-first search algorithm are these:
1. depth-first search stops before searching the whole tree,
if it finds what it's looking for; preorder traversal
always examines the entire tree
2. with depth-first search, searching the right subtree
occurs only if the search of the left subtree failed to
find what was being looked for; with preorder traversal,
the right subtree is always explored (this is sort of a
corollary to the first difference listed just above)
These differences make implementation of depth-first search
more complicated than preorder traversal, but not drastically
so. Here's a simple depth-first search implementation for
the Flintstone Family Tree, using the representation format
for trees given in problem 1 on your first midterm exam. The
tree looks like this in LISP:
'(rocky (pebbles (wilma nil nil) (fred nil nil))
(bam-bam (betty nil nil) (barney nil nil)))
And the LISP code itself looks like this:
(defun dfs (item tree)
(cond ((done? tree) nil)
((found-item? item (get-root tree)) item)
(T (or (dfs item (get-left-subtree tree))
(dfs item (get-right-subtree tree))))))
(defun done? (tree)
(null tree))
(defun found-item? (item tree)
(eql item tree))
(defun get-root (tree)
(first tree))
(defun get-left-subtree (tree)
(second tree))
(defun get-right-subtree (tree)
(third tree))
The use of "or" in the "dfs" function is an easy way to
fulfill the requirement that the right subtree isn't searched
if what we're looking for is found in the left subtree.
However, this may not be great programming style. It's not
an especially obvious use of "or", which is typically used as
a Boolean predicate, not as program control mechanism. Also,
this use of "or" takes advantage of an implementation detail
(i.e., that "or" evaluates its arguments left to right, and
stops as soon as it finds an argument which evaluates to a
non-nil value), which also is not necessarily a great thing
to do. Furthermore, this assumes that any given node has at
most two children; if you want to cope with any number of
children at any node, you'll have to code up a slightly
different version of this anyway. For now, we'll leave the
"or" there, but feel free to do something better.
Copyright 1996 by Kurt Eiselt. All rights reserved.
Last revised: April 25, 1996