Next: About this document
Up: My Home Page
lec3-1.au
Show that for any real constants
a and b, b > 0,
To show , we
must show O and .
Go back to the definition!
Note the need for absolute values.
Modeling
Modeling is the art of formulating your application in terms of precisely
described, well-understood problems.
Proper modeling is the key to applying algorithmic design techniques
to any real-world problem.
Real-world applications involve real-world objects.
Most algorithms, however, are designed to work on rigorously
defined abstract structures
such as permutations, graphs, and sets.
You must first describe your problem abstractly, in terms of fundamental
structures and properties.
Combinatorial Objects
-
Permutations, are arrangements, or orderings, of items.
For example, and are two distinct
permutations of the same set of four integers.
Permutations are likely the object in question whenever your problem
seeks an
``arrangement,'' ``tour,'' ``ordering,'', or ``sequence.''
-
Subsets, which represent selections from a set of items.
For example, and are two distinct subsets of the
first four integers.
Order does not matter in subsets the way it does with permutations, so
the subsets and would be considered identical.
Subsets are likely the object in question whenever your problem
seeks a ``cluster,''
``collection,'' ``committee,'' ``group,'' ``packaging,'' or ``selection.''
-
Strings, which represent sequences of characters or patterns.
For example, the names of students in a class can be represented by
strings.
Strings are likely the object in question whenever you are dealing
with ``text,'' ``characters,'' ``patterns,'' or ``labels.''
Relationship Models
Geometric Objects
-
Points, which represent locations in some geometric space.
For example, the locations of McDonald's restaurants can be described
by points on a map/plane.
Points are likely the object in question whenever your problems
work on ``sites,'' ``positions,'' ``data records,'' or ``locations.''
-
Polygons, which represent regions in some geometric space.
For example, the borders of a country can be described by a polygon
on a map/plane.
Polygons and polyhedra are likely the object in question whenever you
are working on
``shapes,'' ``regions,'' ``configurations,'' or ``boundaries.''
Using the Catalog
These fundamental structures all have associated problems and properties,
which are presented in the catalog of Part II.
Familiarity with all of these problems is important,
because they provide the language we use to model applications.
Understanding all or most of these problems,
even at a cartoon/definition level,
will enable you to know where to look later when the problem
arises in your application.
lec6-10.au
Rules for Algorithm Design
The secret to successful algorithm design, and problem solving in general,
is to make sure you ask the right questions.
Below, I give a possible series of questions for you to ask yourself as
you try to solve difficult algorithm design problems:
-
Do I really understand the problem?
-
What exactly does the input consist of?
-
What exactly are the desired results or output?
-
Can I construct some examples small enough to solve by hand?
What happens when I solve them?
-
Are you trying to solve a numerical problem?
A graph algorithm problem?
A geometric problem?
A string problem?
A set problem?
Might your problem be formulated in more than one way?
Which formulation seems easiest?
-
Can I find a simple algorithm for the problem?
-
Can I find the solve my problem exactly by searching all
subsets or arrangements and picking the best one?
-
If so, why am I sure that this algorithm always gives the correct answer?
-
How do I measure the quality of a solution once I construct it?
lec6-11.au
-
Does this simple, slow solution run in polynomial or exponential time?
-
If I can't find a slow, guaranteed correct algorithm, am I sure
that my problem is well defined enough to permit a solution?
-
Can I solve my problem by repeatedly trying some heuristic rule, like picking
the biggest item first? The smallest item first? A random item first?
-
If so, on what types of inputs does this heuristic rule work well?
Do these correspond to the types of inputs that might arise in the application?
-
On what types of inputs does this heuristic rule work badly?
If no such examples can be found, can I show that in fact it always
works well?
-
How fast does my heuristic rule come up with an answer?
-
Are there special cases of this problem I know how to solve exactly?
-
Can I solve it efficiently when I ignore some of the input parameters?
-
What happens when I set some of the input parameters to trivial values,
such as 0 or 1?
lec6-12.au
-
Can I simplify the problem to create a problem I can solve efficiently?
How simple do I have to make it?
-
If I can solve a certain special case, why can't this be generalized to a
wider class of inputs?
-
Which of the standard algorithm design paradigms seem most relevant to
the problem?
-
Is there a set of items which can be sorted by size or some key?
Does this sorted order make it easier to find what might be the answer?
-
Is there a way to split the problem in two smaller problems,
perhaps by doing a binary search, or a partition of the elements into
big and small, or left and right?
If so, does this suggest a divide-and-conquer algorithm?
-
Are there certain operations being repeatedly done on the same data,
such as searching it for some element, or finding the largest/smallest
remaining element?
If so, can I use a data structure of speed up these queries, like hash tables
or a heap/priority queue?
-
Am I still stumped?
-
Why don't I go back to the beginning of the list and work through the
questions again?
Do any of my answers from the first trip change on the second?
Next: About this document
Up: My Home Page
Steve Skiena
Tue Sep 15 15:44:54 EDT 1998