The.Algorithm.Design.Manual.Springer-Verlag.1998
The.Algorithm.Design.Manual.Springer-Verlag.1998 The.Algorithm.Design.Manual.Springer-Verlag.1998
Modeling the Problem your applications differ from a candidate model. But don't be too quick to say that your problem is unique and special. Temporarily ignoring details that don't fit can free the mind to ask whether they were fundamental in the first place. Next: About the War Stories Up: Introduction to Algorithms Previous: Logarithms Algorithms Mon Jun 2 23:33:50 EDT 1997 file:///E|/BOOK/BOOK/NODE17.HTM (3 of 3) [19/1/2003 1:28:15]
About the War Stories Next: War Story: Psychic Modeling Up: Introduction to Algorithms Previous: Modeling the Problem About the War Stories The best way to become convinced that careful algorithm design can have a significant impact on performance is to look at case studies. By carefully studying other people's experiences, we learn how they might apply to our work. Jon Bentley's Programming Pearls columns are probably the most interesting collection of algorithmic ``war stories'' currently available. Originally published in the Communications of the ACM, they have been collected in two books [Ben86, Ben90]. Fredrick Brooks's The Mythical Man Month [Bro74] is another wonderful collection of war stories, focused more on software engineering than algorithm design, but they remain a source of considerable wisdom. Every programmer should read all three of these books, for pleasure as well as insight. Scattered throughout this text are several of our own war stories, presenting our successful (and occasionally unsuccessful) algorithm design efforts on real applications. We hope that the reader will be able to internalize these experiences so that they will serve as models for their own attacks on problems. Every one of the war stories is true. Of course, the stories improve somewhat in the retelling, and the dialogue has been punched up to make it more interesting to read. However, I have tried to honestly trace the process of going from a raw problem to a solution, so you can watch how the process unfolded. The Oxford English Dictionary defines an algorist as ``one skillful in reckonings or figuring.'' In these stories, I have tried to capture some of the attitude, or mindset, of the algorist in action as they attack a problem. The various war stories usually involve at least one and often several problems from the problem catalog in Part II. The appropriate section of the catalog is referenced wherever it occurs. This emphasizes the benefits of modeling your application in terms of standard algorithm problems. By using the catalog, you will be able to pull out what is known about any problem whenever it is needed. file:///E|/BOOK/BOOK/NODE18.HTM (1 of 2) [19/1/2003 1:28:16]
- Page 73 and 74: References N. Gibbs, W. Poole, and
- Page 75 and 76: References Hof82 Hof89 Hol75 C. M.
- Page 77 and 78: References IK75 Ita78 O. Ibarra and
- Page 79 and 80: References Kir83 D. Kirkpatrick. Ef
- Page 81 and 82: References object in 2-dimensional
- Page 83 and 84: References LT79 LT80 8:99-118, 1995
- Page 85 and 86: References Mil97 V. Milenkovic. Dou
- Page 87 and 88: References Theoretical Computer Sci
- Page 89 and 90: References Pav82 T. Pavlidis. Algor
- Page 91 and 92: References Rei72 Rei91 Rei94 E. Rei
- Page 93 and 94: References Prentice Hall, Englewood
- Page 95 and 96: References SR95 SS71 SS90 SSS74 ST8
- Page 97 and 98: References Tin90 Mikkel Thorup. On
- Page 99 and 100: References Wel84 T. Welch. A techni
- Page 101 and 102: References Algorithms Mon Jun 2 23:
- Page 103 and 104: Correctness and Efficiency Next: Co
- Page 105 and 106: Correctness NearestNeighborTSP(P) P
- Page 107 and 108: Correctness Figure: A bad example f
- Page 109 and 110: Efficiency Next: Expressing Algorit
- Page 111 and 112: Keeping Score Next: The RAM Model o
- Page 113 and 114: The RAM Model of Computation substa
- Page 115 and 116: Best, Worst, and Average-Case Compl
- Page 117 and 118: The Big Oh Notation Figure: Illustr
- Page 119 and 120: Logarithms Next: Modeling the Probl
- Page 121 and 122: Logarithms justified in ignoring th
- Page 123: Modeling the Problem Figure: Modeli
- Page 127 and 128: War Story: Psychic Modeling Next: E
- Page 129 and 130: War Story: Psychic Modeling have pu
- Page 131 and 132: War Story: Psychic Modeling Next: E
- Page 133 and 134: Exercises (b) If I prove that an al
- Page 135 and 136: Fundamental Data Types Next: Contai
- Page 137 and 138: Containers Next: Dictionaries Up: F
- Page 139 and 140: Dictionaries Next: Binary Search Tr
- Page 141 and 142: Binary Search Trees BinaryTreeQuery
- Page 143 and 144: Priority Queues Next: Specialized D
- Page 145 and 146: Specialized Data Structures Next: S
- Page 147 and 148: Sorting Next: Applications of Sorti
- Page 149 and 150: Applications of Sorting Figure: Con
- Page 151 and 152: Data Structures Next: Incremental I
- Page 153 and 154: Incremental Insertion Next: Divide
- Page 155 and 156: Randomization Next: Bucketing Techn
- Page 157 and 158: Randomization Next: Bucketing Techn
- Page 159 and 160: Bucketing Techniques Algorithms Mon
- Page 161 and 162: War Story: Stripping Triangulations
- Page 163 and 164: War Story: Stripping Triangulations
- Page 165 and 166: War Story: Mystery of the Pyramids
- Page 167 and 168: War Story: Mystery of the Pyramids
- Page 169 and 170: War Story: String 'em Up We were co
- Page 171 and 172: War Story: String 'em Up Figure: Su
- Page 173 and 174: Exercises Next: Implementation Chal
Modeling the Problem<br />
your applications differ from a candidate model. But don't be too quick to say that your problem is<br />
unique and special. Temporarily ignoring details that don't fit can free the mind to ask whether they were<br />
fundamental in the first place.<br />
Next: About the War Stories Up: Introduction to <strong>Algorithm</strong>s Previous: Logarithms<br />
<strong>Algorithm</strong>s<br />
Mon Jun 2 23:33:50 EDT 1997<br />
file:///E|/BOOK/BOOK/NODE17.HTM (3 of 3) [19/1/2003 1:28:15]