-
-
--
-If you have not yet answered all the questions yourself, -please go back -here -and do so. -Here are the answers, -from an almanac or similar source. - -
-January 1, 2000, population of the United States is
-272.5 million.
-
-
-Napoleon was born in 1769.
-
-
-The Mississippi-Missouri river is 3,710 miles long.
-
-
-Maximum takeoff weight of a B747-400 airliner
-is 875,000 pounds.
-
-
-A radio signal travels from the earth to the moon
-in 1.29 seconds.
-
-
-Latitude of London is about 51.5 degrees.
-
-
-A space shuttle orbits the earth in about 91 minutes.
-
-
-4200 feet between the towers of the Golden Gate Bridge.
-
-
-56 signers of the
-Declaration of Independence.
-
-
-206 bones in the adult human body.
-
-
-
-
-Please count how many of your ranges included -the correct answer. -Because you used a 90-percent confidence interval, -you should have gotten about nine of the ten answers correct. - -
-If you had all ten answers correct, -then you may be an excellent estimator. -Then again, -your ranges may be way too big. -You can probably guess which. - -
-If you had six or fewer answers correct, -then you are probably as embarrassed as I was when -I first took a similar estimation quiz. -A little practice couldn't hurt your estimation skills. - -
-If you had seven or eight answers correct, -then you are a pretty good guesser. -In the future, -remember to broaden your 90-percent ranges just a bit. - -
-If you had exactly nine answers correct, -then you may be an excellent guesser. -Or, you may have given infinite ranges for the -first nine questions, -and zero for the last question. -If so, shame on you. - -
-Copyright © 1999
-Lucent Technologies. All rights reserved.
-
-Mon 9 Aug 1999
-
-
-
+
+
+
+
+If you have not yet answered all the questions yourself,
+please go back
+here
+and do so.
+Here are the answers,
+from an almanac or similar source.
+
+
+January 1, 2000, population of the United States is
+272.5 million.
+
+
+Please count how many of your ranges included
+the correct answer.
+Because you used a 90-percent confidence interval,
+you should have gotten about nine of the ten answers correct.
+
+
+If you had all ten answers correct,
+then you may be an excellent estimator.
+Then again,
+your ranges may be way too big.
+You can probably guess which.
+
+
+If you had six or fewer answers correct,
+then you are probably as embarrassed as I was when
+I first took a similar estimation quiz.
+A little practice couldn't hurt your estimation skills.
+
+
+If you had seven or eight answers correct,
+then you are a pretty good guesser.
+In the future,
+remember to broaden your 90-percent ranges just a bit.
+
+
+If you had exactly nine answers correct,
+then you may be an excellent guesser.
+Or, you may have given infinite ranges for the
+first nine questions,
+and zero for the last question.
+If so, shame on you.
+
+
+Copyright © 1999
+Lucent Technologies. All rights reserved.
+
+Mon 9 Aug 1999
+
+
+
diff --git a/appmodels.html b/appmodels.html
index 0cfff52..3a75eaa 100644
--- a/appmodels.html
+++ b/appmodels.html
@@ -1,331 +1,331 @@
-
-
-
-
-Section 7.2
-describes two little programs
-for estimating the time and space consumed
-by various primitive operations.
-This appendix shows how those can grow into
-useful programs for generating one-page time
-and space estimates.
-The complete source code for both programs
-can be found at this book's web site.
-
-
-The program spacemod.cpp produces a
-model of the space consumed by various constructs
-in C++.
-The first part of the program uses a sequence
-of statements like
-
-The program also defines a dozen structures,
-using the simple naming convention illustrated
-in these examples:
-
-This macro makes one line of the report:
-
-This table summarizes the output of the program on my machine:
-
-The right column gives us insight into the space overhead
-of the new operator.
-It appears that any structure with a sizeof 12 bytes
-or less will consume 48 bytes.
-Structures with 13 through 28 bytes consume 64 bytes.
-In general,
-the allocated block size will be a multiple of 16,
-with 36 to 47 bytes of overhead.
-This is surprisingly expensive;
-other systems that I use consume just 8 bytes of
-overhead to represent an 8-byte record.
-
-
-Section 7.2
-also describes a little program
-for estimating the cost of one particular C operation.
-We can generalize that to the
-timemod.c
-program that produces
-a one-page cost model for a set of C operations.
-(Brian Kernighan, Chris Van Wyk and I built a
-predecessor of this program in 1991.)
-The main function of that program consists of
-a sequence of a T (for title) lines
-followed by M lines to measure the cost of operations:
-
-This approach gives rough estimates for my machine,
-and they must not be over-interpreted.
-I conducted all experiments with optimization disabled.
-When I enabled that option,
-the optimizer removed the entire timing loops
-and all times were zero.
-
-
-The work is done by the M macro,
-which can be sketched in pseudocode as:
-
-We'll now survey the output of the program
-on my particular system.
-Because the clock clicks are all consistent,
-we will omit them and report only
-the average time in nanoseconds.
-
-The next tests give us insight into control flow
-in general and some sorting operations in particular:
-
-The rand function is relatively inexpensive
-(though recall that the bigrand function makes
-two calls to rand),
-square root is an order of magnitude greater than
-basic arithmetic operations
-(though only twice the cost of a division),
-simple trigonometric operations cost twice that,
-and advanced trigonometric operations run into microseconds.
-
-Copyright © 1999
-Lucent Technologies. All rights reserved.
-
-Mon 9 Aug 1999
-
-
-
+
+
+
+
+Section 7.2
+describes two little programs
+for estimating the time and space consumed
+by various primitive operations.
+This appendix shows how those can grow into
+useful programs for generating one-page time
+and space estimates.
+The complete source code for both programs
+can be found at this book's web site.
+
+
+The program spacemod.cpp produces a
+model of the space consumed by various constructs
+in C++.
+The first part of the program uses a sequence
+of statements like
+
+The program also defines a dozen structures,
+using the simple naming convention illustrated
+in these examples:
+
+This macro makes one line of the report:
+
+This table summarizes the output of the program on my machine:
+
+The right column gives us insight into the space overhead
+of the new operator.
+It appears that any structure with a sizeof 12 bytes
+or less will consume 48 bytes.
+Structures with 13 through 28 bytes consume 64 bytes.
+In general,
+the allocated block size will be a multiple of 16,
+with 36 to 47 bytes of overhead.
+This is surprisingly expensive;
+other systems that I use consume just 8 bytes of
+overhead to represent an 8-byte record.
+
+
+Section 7.2
+also describes a little program
+for estimating the cost of one particular C operation.
+We can generalize that to the
+timemod.c
+program that produces
+a one-page cost model for a set of C operations.
+(Brian Kernighan, Chris Van Wyk and I built a
+predecessor of this program in 1991.)
+The main function of that program consists of
+a sequence of a T (for title) lines
+followed by M lines to measure the cost of operations:
+
+This approach gives rough estimates for my machine,
+and they must not be over-interpreted.
+I conducted all experiments with optimization disabled.
+When I enabled that option,
+the optimizer removed the entire timing loops
+and all times were zero.
+
+
+The work is done by the M macro,
+which can be sketched in pseudocode as:
+
+We'll now survey the output of the program
+on my particular system.
+Because the clock clicks are all consistent,
+we will omit them and report only
+the average time in nanoseconds.
+
+The next tests give us insight into control flow
+in general and some sorting operations in particular:
+
+The rand function is relatively inexpensive
+(though recall that the bigrand function makes
+two calls to rand),
+square root is an order of magnitude greater than
+basic arithmetic operations
+(though only twice the cost of a division),
+simple trigonometric operations cost twice that,
+and advanced trigonometric operations run into microseconds.
+
+Copyright © 1999
+Lucent Technologies. All rights reserved.
+
+Mon 9 Aug 1999
+
+
+
diff --git a/apprules.html b/apprules.html
index 71075a8..af04e73 100644
--- a/apprules.html
+++ b/apprules.html
@@ -1,393 +1,393 @@
-
-
-
-
-My 1982 book
-Writing Efficient Programs
-was built around 27 rules for code tuning.
-That book is now out of print,
-so the rules are repeated here
-(with only a few small changes),
-together with examples of how they are used in this book.
-
-
-Copyright © 1999
-Lucent Technologies. All rights reserved.
-
-Mon 23 Oct 2000
-
-
-
+
+
+
+
+My 1982 book
+Writing Efficient Programs
+was built around 27 rules for code tuning.
+That book is now out of print,
+so the rules are repeated here
+(with only a few small changes),
+together with examples of how they are used in this book.
+
+
+Copyright © 1999
+Lucent Technologies. All rights reserved.
+
+Mon 23 Oct 2000
+
+
+
diff --git a/bitsort.c b/bitsort.c
index 3f7eee4..226b13a 100644
--- a/bitsort.c
+++ b/bitsort.c
@@ -1,8 +1,8 @@
-/* Copyright (C) 1999 Lucent Technologies */
-/* From 'Programming Pearls' by Jon Bentley */
-
-/* bitsort.c -- bitmap sort from Column 1
- * Sort distinct integers in the range [0..N-1]
+/* Copyright (C) 1999 Lucent Technologies */
+/* From 'Programming Pearls' by Jon Bentley */
+
+/* bitsort.c -- bitmap sort from Column 1
+ * Sort distinct integers in the range [0..N-1]
*/
#include
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Copyright © 1999
-Lucent Technologies. All rights reserved.
-
-Fri 3 Sep 1999
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Copyright © 1999
+Lucent Technologies. All rights reserved.
+
+Fri 3 Sep 1999
+
+
diff --git a/bote.html b/bote.html
index 0b129c6..933ab82 100644
--- a/bote.html
+++ b/bote.html
@@ -1,153 +1,153 @@
-
-
-
-
-It was in the middle of a fascinating conversation on
-software engineering that Bob Martin asked me,
-``How much water flows out of the Mississippi River in a day?''
-Because I had found his comments up
-to that point deeply insightful,
-I politely stifled my true response and said, ``Pardon me?''
-When he asked again I realized
-that I had no choice but to humor the poor fellow,
-who had obviously cracked under the pressures of
-running a large software shop.
-
-
-My response went something like this.
-I figured that near its mouth the
-river was about a mile wide and maybe twenty feet deep
-(or about one two-hundred-and-fiftieth of a mile).
-I guessed that the rate of flow was five miles an hour,
-or a hundred and twenty miles per day.
-Multiplying
-
-At that point Martin picked up from his desk a proposal for the
-communication system that his organization was building
-for the Summer Olympic games,
-and went through a similar sequence of calculations.
-He estimated one key parameter as we spoke by
-measuring the time required to send himself a one-character
-piece of mail.
-The rest of his numbers were straight from the proposal
-and therefore quite precise.
-His calculations were just as simple as
-those about the Mississippi River and much more revealing.
-They showed that,
-under generous assumptions,
-the proposed system could work only if there were
-at least a hundred and twenty seconds in each minute.
-He had sent the design back to the drawing board
-the previous day.
-(The conversation took place about a year before the event,
-and the final system
-was used during the Olympics without a hitch.)
-
-
-That was Bob Martin's wonderful (if eccentric) way of
-introducing the engineering technique of
-``back-of-the-envelope'' calculations.
-The idea is standard fare in engineering schools and
-is bread and butter for most practicing engineers.
-Unfortunately, it is too often neglected in computing.
-
-
-The story at the top of this page
-begins Column 7 of Programming Pearls.
-These are the remaining sections in the column.
-
-
-The
-Solutions to Column 7
-give answers for some of the
-Problems.
-
-
-Appendix 2 is an
-estimation quiz
-to help you test your guessing skills.
-
-
-Appendix 3
-describes programs that generate cost models
-for the space (spacemod.cpp)
-and time (timemod.c)
-used by C and C++ programs.
-
-
-The index has an entry for the
-back of the envelope.
-
-
-The teaching material
-contains overhead transparencies based on
-Sections 7.1, 7.5 and 7.6;
-the slides are available in both Postscript
-and Acrobat.
-
-
-The web references
-describe several web sites devoted to this topic.
-
-
-An excerpt from this column appears in the September/October 1999
-issue of
-
-IEEE Software
-(pages 61-65).
-It consists of the lead story,
-much of Section 7.1,
-much of Section 7.2,
-Section 7.5
-and the Estimation Quiz.
-
-
-
-Copyright © 1999
-Lucent Technologies. All rights reserved.
-
-Mon 28 Feb 2000
-
-
-
+
+
+
+
+It was in the middle of a fascinating conversation on
+software engineering that Bob Martin asked me,
+``How much water flows out of the Mississippi River in a day?''
+Because I had found his comments up
+to that point deeply insightful,
+I politely stifled my true response and said, ``Pardon me?''
+When he asked again I realized
+that I had no choice but to humor the poor fellow,
+who had obviously cracked under the pressures of
+running a large software shop.
+
+
+My response went something like this.
+I figured that near its mouth the
+river was about a mile wide and maybe twenty feet deep
+(or about one two-hundred-and-fiftieth of a mile).
+I guessed that the rate of flow was five miles an hour,
+or a hundred and twenty miles per day.
+Multiplying
+
+At that point Martin picked up from his desk a proposal for the
+communication system that his organization was building
+for the Summer Olympic games,
+and went through a similar sequence of calculations.
+He estimated one key parameter as we spoke by
+measuring the time required to send himself a one-character
+piece of mail.
+The rest of his numbers were straight from the proposal
+and therefore quite precise.
+His calculations were just as simple as
+those about the Mississippi River and much more revealing.
+They showed that,
+under generous assumptions,
+the proposed system could work only if there were
+at least a hundred and twenty seconds in each minute.
+He had sent the design back to the drawing board
+the previous day.
+(The conversation took place about a year before the event,
+and the final system
+was used during the Olympics without a hitch.)
+
+
+That was Bob Martin's wonderful (if eccentric) way of
+introducing the engineering technique of
+``back-of-the-envelope'' calculations.
+The idea is standard fare in engineering schools and
+is bread and butter for most practicing engineers.
+Unfortunately, it is too often neglected in computing.
+
+
+The story at the top of this page
+begins Column 7 of Programming Pearls.
+These are the remaining sections in the column.
+
+
+The
+Solutions to Column 7
+give answers for some of the
+Problems.
+
+
+Appendix 2 is an
+estimation quiz
+to help you test your guessing skills.
+
+
+Appendix 3
+describes programs that generate cost models
+for the space (spacemod.cpp)
+and time (timemod.c)
+used by C and C++ programs.
+
+
+The index has an entry for the
+back of the envelope.
+
+
+The teaching material
+contains overhead transparencies based on
+Sections 7.1, 7.5 and 7.6;
+the slides are available in both Postscript
+and Acrobat.
+
+
+The web references
+describe several web sites devoted to this topic.
+
+
+An excerpt from this column appears in the September/October 1999
+issue of
+
+IEEE Software
+(pages 61-65).
+It consists of the lead story,
+much of Section 7.1,
+much of Section 7.2,
+Section 7.5
+and the Estimation Quiz.
+
+
+
+Copyright © 1999
+Lucent Technologies. All rights reserved.
+
+Mon 28 Feb 2000
+
+
+
diff --git a/code.html b/code.html
index 6947b23..fc5f365 100644
--- a/code.html
+++ b/code.html
@@ -1,103 +1,103 @@
-
-
-
-
-Copyright © 1999
-Lucent Technologies. All rights reserved.
-
-Sat 31 Jul 1999
-
-
+
+
+
+
+Copyright © 1999
+Lucent Technologies. All rights reserved.
+
+Sat 31 Jul 1999
+
+
diff --git a/cto.html b/cto.html
index a36cbfe..aa864a3 100644
--- a/cto.html
+++ b/cto.html
@@ -1,159 +1,159 @@
-
-
-
-
-The programmer's question was simple:
-``How do I sort a disk file?''
-Before I tell you how I made my first mistake,
-let me give you a chance to do better than I did.
-What would you have said?
-
-
-My mistake was to answer his question.
-I gave him a thumbnail sketch of how to
-implement a Merge Sort on disk.
-My suggestion that he dig into an algorithms text
-met with less than
-enthusiasm -- he was more concerned about
-solving the problem than furthering his education.
-I then told him about a disk sorting program in
-a popular programming book.
-The program consisted of about two hundred lines
-of code in a dozen functions;
-I estimated that implementing and testing the code
-would have taken the programmer at most a week.
-
-
-I thought that I had solved his problem, but his
-hesitation led me back to the right track.
-The conversation then went something like this, with
-my questions in italics.
-
-The context makes the problem clearer.
-In the United States,
-telephone numbers consist of a three-digit ``area code''
-followed by seven additional digits.
-Telephone calls to numbers with the ``toll-free''
-area code of 800 (the only such code at the time) were not charged.
-A real database of toll-free telephone numbers includes
-a great deal of information:
-the toll-free telephone number,
-the real number to which calls are routed
-(sometimes several numbers,
-with rules on which calls go where when),
-the name and address of the subscriber, and so on.
-
-
-The programmer was building a small corner of
-a system for processing such a database,
-and the integers to be sorted were toll-free telephone numbers.
-The input file was a list of numbers
-(with all other information removed),
-and it was an error to include the same number twice.
-The desired output was a file of the numbers,
-sorted in increasing numeric order.
-The context also defines the performance requirements.
-During a long session with the system,
-the user requested a sorted file roughly
-once an hour and could do nothing until the sort was completed.
-The sort therefore couldn't take more than a few minutes,
-while ten seconds was a more desirable run time.
-
-
-
-These are the remaining sections in the column.
-
-
-The
-Solutions to Column 1
-give answers for some of the
-Problems.
-
-
-Several of the programs in the column and the solutions
-can be found with the other
-source code
-for this book.
-
-
-The web references
-describe web sites related to the topic.
-
-
-An excerpt from this column appears in the November 1999
-issue of
-
-Dr. Dobb's Journal.
-
-
-
-Copyright © 1999
-Lucent Technologies. All rights reserved.
-
-Thu 22 Sep 1999
-
-
-
+
+
+
+
+The programmer's question was simple:
+``How do I sort a disk file?''
+Before I tell you how I made my first mistake,
+let me give you a chance to do better than I did.
+What would you have said?
+
+
+My mistake was to answer his question.
+I gave him a thumbnail sketch of how to
+implement a Merge Sort on disk.
+My suggestion that he dig into an algorithms text
+met with less than
+enthusiasm -- he was more concerned about
+solving the problem than furthering his education.
+I then told him about a disk sorting program in
+a popular programming book.
+The program consisted of about two hundred lines
+of code in a dozen functions;
+I estimated that implementing and testing the code
+would have taken the programmer at most a week.
+
+
+I thought that I had solved his problem, but his
+hesitation led me back to the right track.
+The conversation then went something like this, with
+my questions in italics.
+
+The context makes the problem clearer.
+In the United States,
+telephone numbers consist of a three-digit ``area code''
+followed by seven additional digits.
+Telephone calls to numbers with the ``toll-free''
+area code of 800 (the only such code at the time) were not charged.
+A real database of toll-free telephone numbers includes
+a great deal of information:
+the toll-free telephone number,
+the real number to which calls are routed
+(sometimes several numbers,
+with rules on which calls go where when),
+the name and address of the subscriber, and so on.
+
+
+The programmer was building a small corner of
+a system for processing such a database,
+and the integers to be sorted were toll-free telephone numbers.
+The input file was a list of numbers
+(with all other information removed),
+and it was an error to include the same number twice.
+The desired output was a file of the numbers,
+sorted in increasing numeric order.
+The context also defines the performance requirements.
+During a long session with the system,
+the user requested a sorted file roughly
+once an hour and could do nothing until the sort was completed.
+The sort therefore couldn't take more than a few minutes,
+while ten seconds was a more desirable run time.
+
+
+
+These are the remaining sections in the column.
+
+
+The
+Solutions to Column 1
+give answers for some of the
+Problems.
+
+
+Several of the programs in the column and the solutions
+can be found with the other
+source code
+for this book.
+
+
+The web references
+describe web sites related to the topic.
+
+
+An excerpt from this column appears in the November 1999
+issue of
+
+Dr. Dobb's Journal.
+
+
+
+Copyright © 1999
+Lucent Technologies. All rights reserved.
+
+Thu 22 Sep 1999
+
+
+
diff --git a/epilog1.html b/epilog1.html
index b8e5428..2f19206 100644
--- a/epilog1.html
+++ b/epilog1.html
@@ -1,163 +1,163 @@
-
-
-
-
-An interview with the author seemed, at the time,
-to be the best conclusion for
-the first edition of this book.
-It still describes the book,
-so here it is, once again.
-
- Q:
-Thanks for agreeing to do this interview.
- A:
-No problem -- my time is your time.
-
- Q:
-Seeing how these columns already appeared in
-Communications of the ACM,
-why did you bother to collect them into a book?
- A:
-There are several little reasons:
-I've fixed dozens of errors,
-made hundreds of little improvements, and
-added several new sections.
-There are fifty percent more problems,
-solutions and pictures in the book.
-Also, it's more convenient to have the columns
-in one book rather than a dozen magazines.
-The big reason, though,
-is that the themes running through the columns
-are easier to see when they are collected together;
-the whole is greater than the sum of the parts.
-
- Q:
-What are those themes?
- A:
-The most important is that thinking hard
-about programming can be both useful and fun.
-There's more to the job than systematic
-program development from formal requirements documents.
-If this book helps just one disillusioned programmer
-to fall back in love with his or her work,
-it will have served its purpose.
-
- Q:
-That's a pretty fluffy answer.
-Are there technical threads tying the columns together?
- A:
-Performance is the topic of
-Part II,
-and a theme that runs through all columns.
-Program verification is used extensively in several columns.
-Appendix 1 catalogs the algorithms in the book.
-
-
- Q:
-It seems that most columns emphasize the design process.
-Can you summarize your advice on that topic?
- A:
-I'm glad you asked.
-I just happened to prepare a list before this interview.
-Here are ten suggestions for programmers.
- Q:
-That raises a point that has bothered me:
-it's easy to simplify the little programs in this book,
-but do the techniques scale up to real software?
- A:
-I have three answers: yes, no and maybe.
-Yes they scale up; Section 3.4 [in the first edition],
-for instance,
-describes a huge software project that was
-simplified down to ``just'' 80 staff-years.
-An equally trite answer is no:
-if you simplify properly,
-you avoid building jumbo systems and
-the techniques don't need to scale up.
-Although there is merit in both views,
-the truth lies somewhere in between,
-and that's where the maybe comes in.
-Some software has to be big,
-and the themes of this book are
-sometimes applicable to such systems.
-The Unix system is a fine example of a powerful whole
-built out of simple and elegant parts.
-
- Q:
-There you go talking about another Bell Labs system.
-Aren't these columns a little too parochial?
- A:
-Maybe a little.
-I've stuck to material that I've seen used in practice,
-and that biases the book towards my environment.
-Phrased more positively,
-much of the material in these columns
-was contributed by my colleagues,
-and they deserve the credit (or blame).
-I've learned a lot from many researchers and
-developers within Bell Labs.
-There's a fine corporate atmosphere that encourages
-interaction between research and development.
-So a lot of what you call parochialism
-is just my enthusiasm for my employer.
- Q:
-Let's come back down to earth.
-What pieces are missing from this book?
- A:
-I had hoped to include a large system composed
-of many programs,
-but I couldn't describe any interesting
-systems in the ten or so pages of a typical column.
-At a more general level,
-I'd like to do future columns on the themes of
-``computer science for programmers''
-(like program verification in Column 4 and
-algorithm design in Column 8)
-and the ``engineering techniques of computing''
-(like the
-back-of-the-envelope
-calculations in
-Column 7).
-
- Q:
-If you're so into ``science'' and ``engineering'',
-how come the columns are so light on theorems and tables
-and so heavy on stories?
- A:
-Watch it -- people who interview themselves
-shouldn't criticize writing styles.
-
-
-Copyright © 1999
-Lucent Technologies. All rights reserved.
-
-Fri 24 Sep 1999
-
-
-
+
+
+
+
+An interview with the author seemed, at the time,
+to be the best conclusion for
+the first edition of this book.
+It still describes the book,
+so here it is, once again.
+
+ Q:
+Thanks for agreeing to do this interview.
+ A:
+No problem -- my time is your time.
+
+ Q:
+Seeing how these columns already appeared in
+Communications of the ACM,
+why did you bother to collect them into a book?
+ A:
+There are several little reasons:
+I've fixed dozens of errors,
+made hundreds of little improvements, and
+added several new sections.
+There are fifty percent more problems,
+solutions and pictures in the book.
+Also, it's more convenient to have the columns
+in one book rather than a dozen magazines.
+The big reason, though,
+is that the themes running through the columns
+are easier to see when they are collected together;
+the whole is greater than the sum of the parts.
+
+ Q:
+What are those themes?
+ A:
+The most important is that thinking hard
+about programming can be both useful and fun.
+There's more to the job than systematic
+program development from formal requirements documents.
+If this book helps just one disillusioned programmer
+to fall back in love with his or her work,
+it will have served its purpose.
+
+ Q:
+That's a pretty fluffy answer.
+Are there technical threads tying the columns together?
+ A:
+Performance is the topic of
+Part II,
+and a theme that runs through all columns.
+Program verification is used extensively in several columns.
+Appendix 1 catalogs the algorithms in the book.
+
+
+ Q:
+It seems that most columns emphasize the design process.
+Can you summarize your advice on that topic?
+ A:
+I'm glad you asked.
+I just happened to prepare a list before this interview.
+Here are ten suggestions for programmers.
+ Q:
+That raises a point that has bothered me:
+it's easy to simplify the little programs in this book,
+but do the techniques scale up to real software?
+ A:
+I have three answers: yes, no and maybe.
+Yes they scale up; Section 3.4 [in the first edition],
+for instance,
+describes a huge software project that was
+simplified down to ``just'' 80 staff-years.
+An equally trite answer is no:
+if you simplify properly,
+you avoid building jumbo systems and
+the techniques don't need to scale up.
+Although there is merit in both views,
+the truth lies somewhere in between,
+and that's where the maybe comes in.
+Some software has to be big,
+and the themes of this book are
+sometimes applicable to such systems.
+The Unix system is a fine example of a powerful whole
+built out of simple and elegant parts.
+
+ Q:
+There you go talking about another Bell Labs system.
+Aren't these columns a little too parochial?
+ A:
+Maybe a little.
+I've stuck to material that I've seen used in practice,
+and that biases the book towards my environment.
+Phrased more positively,
+much of the material in these columns
+was contributed by my colleagues,
+and they deserve the credit (or blame).
+I've learned a lot from many researchers and
+developers within Bell Labs.
+There's a fine corporate atmosphere that encourages
+interaction between research and development.
+So a lot of what you call parochialism
+is just my enthusiasm for my employer.
+ Q:
+Let's come back down to earth.
+What pieces are missing from this book?
+ A:
+I had hoped to include a large system composed
+of many programs,
+but I couldn't describe any interesting
+systems in the ten or so pages of a typical column.
+At a more general level,
+I'd like to do future columns on the themes of
+``computer science for programmers''
+(like program verification in Column 4 and
+algorithm design in Column 8)
+and the ``engineering techniques of computing''
+(like the
+back-of-the-envelope
+calculations in
+Column 7).
+
+ Q:
+If you're so into ``science'' and ``engineering'',
+how come the columns are so light on theorems and tables
+and so heavy on stories?
+ A:
+Watch it -- people who interview themselves
+shouldn't criticize writing styles.
+
+
+Copyright © 1999
+Lucent Technologies. All rights reserved.
+
+Fri 24 Sep 1999
+
+
+
diff --git a/epilog2.html b/epilog2.html
index 3a75f76..9a7209f 100644
--- a/epilog2.html
+++ b/epilog2.html
@@ -1,196 +1,196 @@
-
-
-
-
-Some
-traditions
-are continued for their inherent quality.
-Others persist anyway.
-
- Q:
-Welcome back; it's been a long time.
- A:
-Fourteen years.
-
- Q:
-Let's start where we did before.
-Why a new edition of the book?
- A:
-I like the book, a lot.
-It was fun to write,
-and the readers have been very kind over the years.
-The principles in the book
-have stood the test of time,
-but many examples in the
-first edition
-were
-woefully out of date.
-Modern readers can't relate to a ``huge'' computer
-that has a half-megabyte of main memory.
-
- Q:
-So what did you change in this edition?
- A:
-Pretty much
-
-what I said I changed in the preface.
-Don't you guys prepare before these interviews?
-
- Q:
-Oops -- sorry.
-I see that you talk there about how the code
-for this book is available at the web site.
- A:
-Writing that code was the most fun that I had
-in working on this edition.
-I implemented most of the programs in the first edition,
-but mine were the only eyes to see the real code.
-For this edition I wrote about
-2500 lines of C and C++,
-to be shown to the whole world.
-
- Q:
-You call that code ready for public view?
-I've read some of it; what dreadful style!
-Microscopic variable names,
-weird function definitions,
-global variables that should be parameters,
-and the list goes on.
-Aren't you embarrassed to let
-real software engineers see the code?
- A:
-The style I used can indeed prove fatal
-in large software projects.
-This book, however,
-is not a large software project.
-It's not even a large book.
-Solution 5.1
-describes the terse coding style
-and why I chose it.
-Had I wanted to write a thousand-page book,
-I would have adopted a lengthier coding style.
-
- Q:
-Speaking of long code,
-your
-sort.cpp
-program measures the C Standard Library qsort,
-the C++ Standard Template Library sort,
-and several hand-made Quicksorts.
-Can't you make up your mind?
-Should a programmer use library functions
-or build code from scratch?
- A:
-Tom Duff gave the best answer to that question:
-``Whenever possible, steal code.''
-Libraries are great; use them whenever they do the job.
-Start with your system library,
-then search other libraries for appropriate functions.
-In any engineering activity, though,
-not all artifacts can be all things to all customers.
-When the library functions don't measure up,
-you may have to build your own.
-I hope that the pseudocode fragments in the book
-(and the real code on the web site)
-will prove a useful starting point for programmers
-who have to write their own functions.
-I think that the scaffolding and the experimental
-approach of this book will help those programmers to
-evaluate a variety of algorithms and choose the
-best one for their application.
-
- Q:
-Apart from the public code and updating some stories,
-what is really new in this edition?
- A:
-I've tried to confront code tuning in the
-presence of caches and instruction-level parallelism.
-At a larger level,
-the three new columns reflect
-three major changes that pervade this edition:
-Column 5 describes real code and scaffolding,
-Column 13 gives details on data structures, and
-Column 15
-derives advanced algorithms.
-Most of the ideas in the book have appeared in
-print before,
-but the cost model for space in
-Appendix 3
-and the Markov-text algorithm in
-Section 15.3
-are presented here for the first time.
-The new Markov-text algorithm compares quite
-favorably to the classic algorithm described by
-Kernighan and Pike.
-
- Q:
-There you go with more Bell Labs people.
-The last time we talked,
-you were enthusiastic about the place,
-but you had only been there a few years.
-Lots has changed at the Labs in the last 14 years;
-what do you now think about the place and the changes?
- A:
-When I wrote the first columns in the book,
-Bell Labs
-was part of the Bell System.
-When the first edition was published,
-we were part of AT&T;
-now we are part of
-Lucent Technologies.
-The companies,
-the telecommunications industry,
-and the field of computing
-have all changed dramatically in that period.
-Bell Labs
-has kept up with those changes,
-and has often led the way.
-I came to the Labs because I enjoy balancing
-the theoretical and the applied,
-because I want to build products and write books.
-The pendulum has swung back and forth during
-my years at the Labs,
-but my management has always encouraged
-a wide range of activities.
-
-
-A reviewer of the first edition of this book
-wrote
-``Bentley's everyday working environment is
-a programming nirvana.
-He is a Member of Technical Staff at
-Bell Labs
-in
-
-Murray Hill,
-New Jersey,
-has immediate access to cutting-edge hardware
-and software technology,
-and stands in line at the cafeteria with some
-of the most brilliant software developers in the world.''
-Bell Labs is still that kind of place.
-
- Q:
-Nirvana every single day of the week?
- A:
-Nirvana many days,
-and pretty darn nice the others.
-
-
-Copyright © 1999
-Lucent Technologies. All rights reserved.
-
-Fri 24 Sep 1999
-
-
-
+
+
+
+
+Some
+traditions
+are continued for their inherent quality.
+Others persist anyway.
+
+ Q:
+Welcome back; it's been a long time.
+ A:
+Fourteen years.
+
+ Q:
+Let's start where we did before.
+Why a new edition of the book?
+ A:
+I like the book, a lot.
+It was fun to write,
+and the readers have been very kind over the years.
+The principles in the book
+have stood the test of time,
+but many examples in the
+first edition
+were
+woefully out of date.
+Modern readers can't relate to a ``huge'' computer
+that has a half-megabyte of main memory.
+
+ Q:
+So what did you change in this edition?
+ A:
+Pretty much
+
+what I said I changed in the preface.
+Don't you guys prepare before these interviews?
+
+ Q:
+Oops -- sorry.
+I see that you talk there about how the code
+for this book is available at the web site.
+ A:
+Writing that code was the most fun that I had
+in working on this edition.
+I implemented most of the programs in the first edition,
+but mine were the only eyes to see the real code.
+For this edition I wrote about
+2500 lines of C and C++,
+to be shown to the whole world.
+
+ Q:
+You call that code ready for public view?
+I've read some of it; what dreadful style!
+Microscopic variable names,
+weird function definitions,
+global variables that should be parameters,
+and the list goes on.
+Aren't you embarrassed to let
+real software engineers see the code?
+ A:
+The style I used can indeed prove fatal
+in large software projects.
+This book, however,
+is not a large software project.
+It's not even a large book.
+Solution 5.1
+describes the terse coding style
+and why I chose it.
+Had I wanted to write a thousand-page book,
+I would have adopted a lengthier coding style.
+
+ Q:
+Speaking of long code,
+your
+sort.cpp
+program measures the C Standard Library qsort,
+the C++ Standard Template Library sort,
+and several hand-made Quicksorts.
+Can't you make up your mind?
+Should a programmer use library functions
+or build code from scratch?
+ A:
+Tom Duff gave the best answer to that question:
+``Whenever possible, steal code.''
+Libraries are great; use them whenever they do the job.
+Start with your system library,
+then search other libraries for appropriate functions.
+In any engineering activity, though,
+not all artifacts can be all things to all customers.
+When the library functions don't measure up,
+you may have to build your own.
+I hope that the pseudocode fragments in the book
+(and the real code on the web site)
+will prove a useful starting point for programmers
+who have to write their own functions.
+I think that the scaffolding and the experimental
+approach of this book will help those programmers to
+evaluate a variety of algorithms and choose the
+best one for their application.
+
+ Q:
+Apart from the public code and updating some stories,
+what is really new in this edition?
+ A:
+I've tried to confront code tuning in the
+presence of caches and instruction-level parallelism.
+At a larger level,
+the three new columns reflect
+three major changes that pervade this edition:
+Column 5 describes real code and scaffolding,
+Column 13 gives details on data structures, and
+Column 15
+derives advanced algorithms.
+Most of the ideas in the book have appeared in
+print before,
+but the cost model for space in
+Appendix 3
+and the Markov-text algorithm in
+Section 15.3
+are presented here for the first time.
+The new Markov-text algorithm compares quite
+favorably to the classic algorithm described by
+Kernighan and Pike.
+
+ Q:
+There you go with more Bell Labs people.
+The last time we talked,
+you were enthusiastic about the place,
+but you had only been there a few years.
+Lots has changed at the Labs in the last 14 years;
+what do you now think about the place and the changes?
+ A:
+When I wrote the first columns in the book,
+Bell Labs
+was part of the Bell System.
+When the first edition was published,
+we were part of AT&T;
+now we are part of
+Lucent Technologies.
+The companies,
+the telecommunications industry,
+and the field of computing
+have all changed dramatically in that period.
+Bell Labs
+has kept up with those changes,
+and has often led the way.
+I came to the Labs because I enjoy balancing
+the theoretical and the applied,
+because I want to build products and write books.
+The pendulum has swung back and forth during
+my years at the Labs,
+but my management has always encouraged
+a wide range of activities.
+
+
+A reviewer of the first edition of this book
+wrote
+``Bentley's everyday working environment is
+a programming nirvana.
+He is a Member of Technical Staff at
+Bell Labs
+in
+
+Murray Hill,
+New Jersey,
+has immediate access to cutting-edge hardware
+and software technology,
+and stands in line at the cafeteria with some
+of the most brilliant software developers in the world.''
+Bell Labs is still that kind of place.
+
+ Q:
+Nirvana every single day of the week?
+ A:
+Nirvana many days,
+and pretty darn nice the others.
+
+
+Copyright © 1999
+Lucent Technologies. All rights reserved.
+
+Fri 24 Sep 1999
+
+
+
diff --git a/errata.html b/errata.html
index 8156ca7..f7dceb3 100644
--- a/errata.html
+++ b/errata.html
@@ -1,73 +1,73 @@
-
-
-
-
-The second printing had no changes from the first printing.
-
-
-The following bugs need to be fixed in upcoming printings.
-
-
-p. 38, line 23. The clause cantbe(m, n) should be
-cantbe(m, n-1).
-
-
-p. 121, line 11: The inequality sign is reversed; the test should read
-``if u-l < cutoff''.
-(The test is correct in the function qsort4 later on the page.)
-
-
-p. 129, line -14: The variables ``m''
-and ``n'' are swapped.
-The sentence should read:
-``Next, suppose that m is ten million
-and n is 231.''
-
-
-p. 181, line -6:
-Change ``structues'' to ``structures''.
-
-
-p. 203, line 12:
-Change ``commutative'' to ``associative''.
-
-
-p. 224, line -2: Remove the phrase
-``or print n + 1 - i rather than i''.
-
-
-p. 231, line -13: Insert ``p'' after ``*'',
-so the line reads
-
-I am grateful for the extremely careful reading
-and detailed bug reports provided by
-Nick Cox,
-Alexey Kudravtsev,
-Dan Pape,
-Arnold Robbins
-and Satoru Takabayashi.
-
-
-
-Copyright © 1999
-Lucent Technologies. All rights reserved.
-
-We 15 Nov 2000
-
-
-
+
+
+
+
+The second printing had no changes from the first printing.
+
+
+The following bugs need to be fixed in upcoming printings.
+
+
+p. 38, line 23. The clause cantbe(m, n) should be
+cantbe(m, n-1).
+
+
+p. 121, line 11: The inequality sign is reversed; the test should read
+``if u-l < cutoff''.
+(The test is correct in the function qsort4 later on the page.)
+
+
+p. 129, line -14: The variables ``m''
+and ``n'' are swapped.
+The sentence should read:
+``Next, suppose that m is ten million
+and n is 231.''
+
+
+p. 181, line -6:
+Change ``structues'' to ``structures''.
+
+
+p. 203, line 12:
+Change ``commutative'' to ``associative''.
+
+
+p. 224, line -2: Remove the phrase
+``or print n + 1 - i rather than i''.
+
+
+p. 231, line -13: Insert ``p'' after ``*'',
+so the line reads
+
+I am grateful for the extremely careful reading
+and detailed bug reports provided by
+Nick Cox,
+Alexey Kudravtsev,
+Dan Pape,
+Arnold Robbins
+and Satoru Takabayashi.
+
+
+
+Copyright © 1999
+Lucent Technologies. All rights reserved.
+
+We 15 Nov 2000
+
+
+
diff --git a/firsted.html b/firsted.html
index 07f57d6..b390096 100644
--- a/firsted.html
+++ b/firsted.html
@@ -1,189 +1,189 @@
-
-
-
-
-
-The first edition of Programming Pearls was published by
-Addison-Wesley, Inc., 1986.
-
-I talked about how much I enjoyed the first edition
-when I described
-why I wrote a second edition.
-Other people like the book, too.
-
-
-Steve McConnell
-put Programming Pearls
-on the
-
-Top-Ten List
-in his
-Code Complete.
-He says that the book is ``a vigorous discussion of
-programming that articulates the reasons that some of us
-find programming so interesting.
-The fact that the information isn't comprehensive or rigidly organized
-doesn't prevent it from conveying powerful insights that you'll
-read in a few minutes and use for many years.''
-
-
-In an
-
-Association of C and C++ Users
-
-Book Review
-Francis Glassborow says that it
-``is another of those rare computing books
-that manages to stand the test of time''
-and that
-``it has a place on every programmer's bookshelf''.
-
-
-Programming Pearls made the list of
-
-Great Books
-that Gregory V. Wilson prepared for
-
-Dr. Dobb's Electronic Review of Computer Books.
-The book is also described in Ray Duncan's
-
-Confessions of an Efficient Coder
-in the same series.
-
-
-The first edition of Programming Pearls earned five stars at
-Amazon.com.
-The
-
-readers' comments
-include
-``a gem'',
-``the small book is itself a pearl'',
-``a manual with hacker spirit!'',
-and
-``best book about how to `think' for software engineering''.
-
-
-K. N. King
-put Programming Pearls on his list of
-
-recommended books.
-``The author's light touch makes the
-book as enjoyable to read as it is informative.''
-
-
-Other comments on Programming Pearls:
-
-
-enough fresh insights to make this a real bookshelf treasure
-
-
-
-[a book] that I think everyone should read
-
-
-
-[a book] that changed me
-
-
-
-lots of useful lessons in the craft
-
-
-
-an important, classic book
-
-
-
-clever language solutions to common programming problems
-
-
-
-one of the best books I know on general issues in programming
-
-
-
-list of recommended programming books
-
-
-
-very entertaining articles
-
-
-
-books I can recommend
-
-
-
-a brilliant book
-
-
-
-one of the most thoughtful gifts I have ever received
-
-
-
-
-From
-Microsoft Secrets:
-How the World's Most Powerful Company
-Creates Technology, Shapes Markets,
-and Manages People,
-by Michael Cusumano and Richard Selby
-(The Free Press, A Division of Simon & Schuster Inc.,
-NY, NY, 1995), p. 112:
-
-
-``The mentoring system?
-Actually, that's not broken....
-There are certain things,
-certain algorithmic techniques and things.
-But give the guy a copy of Programming Pearls,
-make sure he's read through the thing and understands
-everything in there.
-Show him a piece of code.
-Ask him some questions about it....''
-
-
-
-Copyright © 1999
-Lucent Technologies. All rights reserved.
-
-Thu 30 Sep 1999
-
-
-
+
+
+
+
+
+The first edition of Programming Pearls was published by
+Addison-Wesley, Inc., 1986.
+
+I talked about how much I enjoyed the first edition
+when I described
+why I wrote a second edition.
+Other people like the book, too.
+
+
+Steve McConnell
+put Programming Pearls
+on the
+
+Top-Ten List
+in his
+Code Complete.
+He says that the book is ``a vigorous discussion of
+programming that articulates the reasons that some of us
+find programming so interesting.
+The fact that the information isn't comprehensive or rigidly organized
+doesn't prevent it from conveying powerful insights that you'll
+read in a few minutes and use for many years.''
+
+
+In an
+
+Association of C and C++ Users
+
+Book Review
+Francis Glassborow says that it
+``is another of those rare computing books
+that manages to stand the test of time''
+and that
+``it has a place on every programmer's bookshelf''.
+
+
+Programming Pearls made the list of
+
+Great Books
+that Gregory V. Wilson prepared for
+
+Dr. Dobb's Electronic Review of Computer Books.
+The book is also described in Ray Duncan's
+
+Confessions of an Efficient Coder
+in the same series.
+
+
+The first edition of Programming Pearls earned five stars at
+Amazon.com.
+The
+
+readers' comments
+include
+``a gem'',
+``the small book is itself a pearl'',
+``a manual with hacker spirit!'',
+and
+``best book about how to `think' for software engineering''.
+
+
+K. N. King
+put Programming Pearls on his list of
+
+recommended books.
+``The author's light touch makes the
+book as enjoyable to read as it is informative.''
+
+
+Other comments on Programming Pearls:
+
+
+enough fresh insights to make this a real bookshelf treasure
+
+
+
+[a book] that I think everyone should read
+
+
+
+[a book] that changed me
+
+
+
+lots of useful lessons in the craft
+
+
+
+an important, classic book
+
+
+
+clever language solutions to common programming problems
+
+
+
+one of the best books I know on general issues in programming
+
+
+
+list of recommended programming books
+
+
+
+very entertaining articles
+
+
+
+books I can recommend
+
+
+
+a brilliant book
+
+
+
+one of the most thoughtful gifts I have ever received
+
+
+
+
+From
+Microsoft Secrets:
+How the World's Most Powerful Company
+Creates Technology, Shapes Markets,
+and Manages People,
+by Michael Cusumano and Richard Selby
+(The Free Press, A Division of Simon & Schuster Inc.,
+NY, NY, 1995), p. 112:
+
+
+``The mentoring system?
+Actually, that's not broken....
+There are certain things,
+certain algorithmic techniques and things.
+But give the guy a copy of Programming Pearls,
+make sure he's read through the thing and understands
+everything in there.
+Show him a piece of code.
+Ask him some questions about it....''
+
+
+
+Copyright © 1999
+Lucent Technologies. All rights reserved.
+
+Thu 30 Sep 1999
+
+
+
diff --git a/fyi.html b/fyi.html
index 416ba80..f6dd699 100644
--- a/fyi.html
+++ b/fyi.html
@@ -1,157 +1,157 @@
-
-
-
-
-Owen Astrachan
-organized a
-
-Workshop on First Year Instruction
-sponsored by the
-National Science Foundation
-and the
-
-Duke University Computer Science Department
-in July, 2000.
-When he invited me to give the keynote,
-my first response was that I haven't taught a freshman
-course for a quarter of a century.
-
-
-On the other hand,
-I've enjoyed talking to undergraduates over the years,
-and Programming Pearls has been widely used
-as a supplementary text in college courses.
-My interest in the topic was also increased because
-my son was heading off to college later that summer.
-With Owen's guidance and encouragement,
-I agreed to talk on ``Truth, Beauty, and Engineering:
-What I'd Like My CS Freshman Kid to Learn Next Year''.
-(Let me clarify as a proud parent that Computer Science
-was only one of several possible majors that he was
-considering as he departed;
-I have high hopes that he can avoid repeating the sins
-of his father.)
-
-
-The talk is available as a
-Powerpoint Show.
-It has this rough outline:
-
-This topic has
-its own web page,
-complete with a talk.
-
-
-
-Elegance is the moral of
-Column 1,
-and a theme through the rest of the book,
-complete with its own
-entry in the index.
-For a more general view of the topic,
-see the
-Computerworld
-article on
-
-Elegance
-in software.
-
-
-I had the luxury of striving for elegance in the
-source code
-for the book.
-The scaffolding is often (appropriately) rough,
-but I took same pains to trim excess fat from most of the code
-that found its way into the text.
-
-
-
-The book is peppered with little historical anecdotes
-that illustrate timeless truths.
-Section 10.1 introduces the topic of ``squeezing space''
-with this story from the dawn of computing:
-
-
-``Fred Brooks observed the power of simplification
-when he wrote a payroll program
-for a national company in the mid 1950's.
-The bottleneck of the program was the representation of the
-Kentucky state income tax.
-The tax was specified in the law by a two-dimensional table
-with income as one dimension,
-and number of exemptions as the other.
-Storing the table explicitly required
-thousands of words of memory,
-more than the capacity of the machine.
-
-
-``The first approach Brooks
-tried was to fit a mathematical function through the tax table,
-but it was so jagged that no simple function would come close.
-Knowing that it was made by legislators
-with no predisposition to crazy mathematical functions,
-Brooks consulted the minutes of the Kentucky legislature
-to see what arguments had led to the bizarre table.
-He found that the Kentucky tax was
-a simple function of the income that remained
-after federal tax was deducted.
-His program therefore calculated federal tax from existing tables,
-and then used the remaining income and a table
-of just a few dozen words of memory to find the Kentucky tax.
-
-
-``By studying the context in which the problem arose,
-Brooks was able to replace the original problem to be solved
-with a simpler problem.
-While the original problem appeared to require
-thousands of words of data space,
-the modified problem was solved with
-a negligible amount of memory.''
-
-
-I tried to sprinkle such historical nuggets throughout the book.
-From the 1960's,
-Sections 2.4 and 2.8 describe a program for computing anagrams,
-and Section 9.3 describes a svelte binary search.
-From the 1970's,
-Problem 2.6 describes a touch-tone phone directory,
-Column 8 describes the evolution of an algorithm,
-Section 10.3 describes storing symmetric matrices,
-and Section 15.2 describes suffix arrays.
-
-
-
-Copyright © 2000
-Lucent Technologies. All rights reserved.
-
-Mon 3 Jul 2000
-
-
-
+
+
+
+
+Owen Astrachan
+organized a
+
+Workshop on First Year Instruction
+sponsored by the
+National Science Foundation
+and the
+
+Duke University Computer Science Department
+in July, 2000.
+When he invited me to give the keynote,
+my first response was that I haven't taught a freshman
+course for a quarter of a century.
+
+
+On the other hand,
+I've enjoyed talking to undergraduates over the years,
+and Programming Pearls has been widely used
+as a supplementary text in college courses.
+My interest in the topic was also increased because
+my son was heading off to college later that summer.
+With Owen's guidance and encouragement,
+I agreed to talk on ``Truth, Beauty, and Engineering:
+What I'd Like My CS Freshman Kid to Learn Next Year''.
+(Let me clarify as a proud parent that Computer Science
+was only one of several possible majors that he was
+considering as he departed;
+I have high hopes that he can avoid repeating the sins
+of his father.)
+
+
+The talk is available as a
+Powerpoint Show.
+It has this rough outline:
+
+This topic has
+its own web page,
+complete with a talk.
+
+
+
+Elegance is the moral of
+Column 1,
+and a theme through the rest of the book,
+complete with its own
+entry in the index.
+For a more general view of the topic,
+see the
+Computerworld
+article on
+
+Elegance
+in software.
+
+
+I had the luxury of striving for elegance in the
+source code
+for the book.
+The scaffolding is often (appropriately) rough,
+but I took same pains to trim excess fat from most of the code
+that found its way into the text.
+
+
+
+The book is peppered with little historical anecdotes
+that illustrate timeless truths.
+Section 10.1 introduces the topic of ``squeezing space''
+with this story from the dawn of computing:
+
+
+``Fred Brooks observed the power of simplification
+when he wrote a payroll program
+for a national company in the mid 1950's.
+The bottleneck of the program was the representation of the
+Kentucky state income tax.
+The tax was specified in the law by a two-dimensional table
+with income as one dimension,
+and number of exemptions as the other.
+Storing the table explicitly required
+thousands of words of memory,
+more than the capacity of the machine.
+
+
+``The first approach Brooks
+tried was to fit a mathematical function through the tax table,
+but it was so jagged that no simple function would come close.
+Knowing that it was made by legislators
+with no predisposition to crazy mathematical functions,
+Brooks consulted the minutes of the Kentucky legislature
+to see what arguments had led to the bizarre table.
+He found that the Kentucky tax was
+a simple function of the income that remained
+after federal tax was deducted.
+His program therefore calculated federal tax from existing tables,
+and then used the remaining income and a table
+of just a few dozen words of memory to find the Kentucky tax.
+
+
+``By studying the context in which the problem arose,
+Brooks was able to replace the original problem to be solved
+with a simpler problem.
+While the original problem appeared to require
+thousands of words of data space,
+the modified problem was solved with
+a negligible amount of memory.''
+
+
+I tried to sprinkle such historical nuggets throughout the book.
+From the 1960's,
+Sections 2.4 and 2.8 describe a program for computing anagrams,
+and Section 9.3 describes a svelte binary search.
+From the 1970's,
+Problem 2.6 describes a touch-tone phone directory,
+Column 8 describes the evolution of an algorithm,
+Section 10.3 describes storing symmetric matrices,
+and Section 15.2 describes suffix arrays.
+
+
+
+Copyright © 2000
+Lucent Technologies. All rights reserved.
+
+Mon 3 Jul 2000
+
+
+
diff --git a/genbins.c b/genbins.c
index 1971deb..fc3001c 100644
--- a/genbins.c
+++ b/genbins.c
@@ -1,94 +1,94 @@
-/* Copyright (C) 1999 Lucent Technologies */
-/* From 'Programming Pearls' by Jon Bentley */
-
-/* genbins.c -- generate random numbers with bins */
-
-/* If NODESIZE is 8, this program uses the special-case malloc.
- Change NODESIZE to 0 to use the system malloc.
- */
-
-#include
-
-Addison-Wesley, Inc., 2000.
-
-
-
-This book is a collection of essays about
-a glamorous aspect of software:
-programming pearls whose origins lie beyond solid engineering,
-in the realm of insight and creativity.
-This book provides a guide for both students
-and experienced programmers
-about how to design and create programs,
-and how to think about programming.
-
-
-The book is full of small case studies, real examples,
-and interesting exercises for learning about how to program.
-This web page contains samples
-from the whole work for you to investigate.
-For teachers, the links below lead to some of the
-central material suitable for classroom use.
-
-
-Steve McConnell describes the book as
-``a celebration of design in the small''.
-Browse this site to sample it yourself.
-
-
-
- From The Book
- About The Book
- Supporting Material
- Other Links
-
-
-Copyright © 1999
-Lucent Technologies. All rights reserved.
-
-Thu 19 Oct 2000
-
-
-
+
+
+
+
+Addison-Wesley, Inc., 2000.
+
+
+
+This book is a collection of essays about
+a glamorous aspect of software:
+programming pearls whose origins lie beyond solid engineering,
+in the realm of insight and creativity.
+This book provides a guide for both students
+and experienced programmers
+about how to design and create programs,
+and how to think about programming.
+
+
+The book is full of small case studies, real examples,
+and interesting exercises for learning about how to program.
+This web page contains samples
+from the whole work for you to investigate.
+For teachers, the links below lead to some of the
+central material suitable for classroom use.
+
+
+Steve McConnell describes the book as
+``a celebration of design in the small''.
+Browse this site to sample it yourself.
+
+
+
+ From The Book
+ About The Book
+ Supporting Material
+ Other Links
+
+
+Copyright © 1999
+Lucent Technologies. All rights reserved.
+
+Thu 19 Oct 2000
+
+
+
diff --git a/longdup.c b/longdup.c
index d06a0e4..ba0c62f 100644
--- a/longdup.c
+++ b/longdup.c
@@ -1,6 +1,6 @@
-/* Copyright (C) 1999 Lucent Technologies */
-/* From 'Programming Pearls' by Jon Bentley */
-
+/* Copyright (C) 1999 Lucent Technologies */
+/* From 'Programming Pearls' by Jon Bentley */
+
/* longdup.c -- Print longest string duplicated M times */
#include
-
-Section 15.2
-describes long repeated strings in text and gives
-an example.
-Here are some more examples,
-generated
-by this program
-from several sources.
-
-
-
-This text is found in 2 Kings 20:13 and in Isaiah 39:2.
-Each text line in the original file begins with the chapter and verse
-(i.e., ``GEN 1:1 In the beginning God created ...'').
-Long repeated strings therefore could not cross verse boundaries;
-the next experiment deleted those identifiers.
-
-
-
-
-Numbers 7 describes offerings made over a period of twelve days;
-much of this string appears twelve times.
-
-
-
-
-This string occurs twelve times in Numbers 7.
-This string was computed using the method of
-Solution 15.8.
-
-
-
-
-I was surprised to find that the longest repeated string in the
-book was in the index.
-The same sequence of numbers are repeated for the entries for
-``experiments'', ``run time'' and ``time, run''.
-
-
-
-This text appears in both the Logic Rules and the Expression Rules of
-Appendix 4: Rules for Code Tuning.
-
-
-
-
-
-This example
-(on Samuel Butler's translation of Homer's Iliad)
-was used in
-Section 15.2.
-describes long repeated strings in text and gives
-The text first occurs when Juno suggests it
-to Minerva as an argument that might keep
-the Greeks (Achaeans) from departing from Troy;
-it occurs shortly thereafter when Minerva
-repeats the argument verbatim to Ulysses.
-
-
-
-
-Copyright © 1999
-Lucent Technologies. All rights reserved.
-
-Mon 6 Nov 2000
-
-
-
+
+
+
+
+Section 15.2
+describes long repeated strings in text and gives
+an example.
+Here are some more examples,
+generated
+by this program
+from several sources.
+
+
+
+This text is found in 2 Kings 20:13 and in Isaiah 39:2.
+Each text line in the original file begins with the chapter and verse
+(i.e., ``GEN 1:1 In the beginning God created ...'').
+Long repeated strings therefore could not cross verse boundaries;
+the next experiment deleted those identifiers.
+
+
+
+
+Numbers 7 describes offerings made over a period of twelve days;
+much of this string appears twelve times.
+
+
+
+
+This string occurs twelve times in Numbers 7.
+This string was computed using the method of
+Solution 15.8.
+
+
+
+
+I was surprised to find that the longest repeated string in the
+book was in the index.
+The same sequence of numbers are repeated for the entries for
+``experiments'', ``run time'' and ``time, run''.
+
+
+
+This text appears in both the Logic Rules and the Expression Rules of
+Appendix 4: Rules for Code Tuning.
+
+
+
+
+
+This example
+(on Samuel Butler's translation of Homer's Iliad)
+was used in
+Section 15.2.
+describes long repeated strings in text and gives
+The text first occurs when Juno suggests it
+to Minerva as an argument that might keep
+the Greeks (Achaeans) from departing from Troy;
+it occurs shortly thereafter when Minerva
+repeats the argument verbatim to Ulysses.
+
+
+
+
+Copyright © 1999
+Lucent Technologies. All rights reserved.
+
+Mon 6 Nov 2000
+
+
+
diff --git a/macfun.c b/macfun.c
index 63f066c..7cd210f 100644
--- a/macfun.c
+++ b/macfun.c
@@ -1,6 +1,6 @@
-/* Copyright (C) 1999 Lucent Technologies */
-/* From 'Programming Pearls' by Jon Bentley */
-
+/* Copyright (C) 1999 Lucent Technologies */
+/* From 'Programming Pearls' by Jon Bentley */
+
/* macfun.c -- time macro and function implementations of max
* Input: a sequence of (alg num, n) pairs.
* Output: for each test, (alg num, n, ans, ticks, secs)
@@ -18,12 +18,12 @@ float x[MAXN];
#define max1(a, b) ((a) > (b) ? (a) : (b))
-float arrmax1(int n)
-{ if (n == 1)
- return x[0];
- else
- return max1(x[n-1], arrmax1(n-1));
-}
+float arrmax1(int n)
+{ if (n == 1)
+ return x[0];
+ else
+ return max1(x[n-1], arrmax1(n-1));
+}
/* arrmax2 -- max is a function */
@@ -72,6 +72,6 @@ int main()
clicks = clock()-start;
printf("%d\t%d\t%g\t%d\t%g\n", algnum, n, thisans,
clicks, clicks / (float) CLOCKS_PER_SEC);
- }
+ }
return 0;
}
diff --git a/markov.c b/markov.c
index 8bfaf68..ea3f5b9 100644
--- a/markov.c
+++ b/markov.c
@@ -62,6 +62,6 @@ int main()
if (strlen(skip(phrase, k-1)) == 0)
break;
printf("%s\n", skip(phrase, k-1));
- }
+ }
return 0;
}
diff --git a/markovhash.c b/markovhash.c
index 173f0fc..e98162a 100644
--- a/markovhash.c
+++ b/markovhash.c
@@ -1,90 +1,90 @@
-/* Copyright (C) 1999 Lucent Technologies */
-/* From 'Programming Pearls' by Jon Bentley */
-
-/* markovhash.c -- generate random text, sped up with hash tables */
-
-/* For storage efficiency (and also to minimize changes from markov.c),
- the hash table is implemented in the integer array next.
- If bin[i]=j, then word[j] is the first element in the list,
- word[next[j]] is the next element, and so on.
- */
-
-#include
-
-Section 15.3
-describes letter-level Markov text and gives
-a few examples.
-Here are some more examples,
-generated
-by this program
-from several sources.
-
-
-
-Order-1:
-Runs ch g Sprif ighaifay fe; ie llathis, fur Gos ngithigh
-f Lom sist aminth uces yom Je Movin th we hof I juthe peathor ly dis
-igstredithe the, ist oth t s th uth re? hathlivicoto burecon on, Forer
-mautht w Lowepe sucthet nese, optro cl cth, alditheakengerdisa of bea
-wepis nd on ichencouteeinthtemef id, n thard f heans rat ithooowh,
-halang s mail whet alf it th, avoterd myond che su: pulece t hethy
-tinen, Forund ur; h, y tousio
-
-
-Order-2:
-For unto yousay law to do retway hein: thein ther on, Who dopento the
-he but wit forethered Jesin: ach minto at of the livence, wholet ye
-judge of heren the me of th. Ford fulne, andethe a refor oure dowe
-God he hathess. Becom thers, bed hat the sing ousne any med boanined
-that wer praoh, aryphe knot that law of the ef: I mints Chrom home
-insgrahalso ded ford to wits norks: but san, wrace to thento the sid;
-have all the as ith: buth. To antiondignam to unte of So now the
-rise selievelesed law; As sh to but is of tore wrink mignot him pe:
-ford me, to prough ithe ard be. Forke eare st; expe counto the pe he
-is abled an he again forears, the be not de, lesion thre th, Whou
-witilethaturer an ofesusned to pon aw.
-
-
-Order-3:
-For righbour in from her own Sion, There not, which
-confidentillined; For thereignation and thes ves: things is gospel,
-do nothink wised; and root is of the law? of unto him which hearath ye
-werefor the est, but child seeth; But neithough them what life.
-But wise workenned in their we knowing to them whets of
-Jesurreceivereus, and, and commit is unwise anot, deated are trivet;
-in put God, thy meat who what want ought, which and thereignor God
-same by the circumcision. As it wise himselves deate.
-
-
-Order-4:
-Therein the law to Gomorrha. Owe not atten for it was lieth
-believed. The gosperously report? For Israel, not in business
-shalt not hope. For I receiving the works: unto these to that in my
-hundred you: for of God, the changed began, which is thou, nor all
-thing as by the law of Christ uncircumcised the me infirmity
-againstanding and Sarah's way the carnally preferring inst alive the
-law, thou the law of sin; and bitten as by ther.
-
-
-Order-5:
-What their lusts there in your father, because also maketh not, it
-is among ought of his he liveth, if it fulfil things which cause
-division verily, the gospel of God. For I be saved. For they have
-mercy. Now if thou boast of patience of envy, murder, debate,
-deceive tree, which are the righteousness. Much more shall rise
-thankful; but have you into Spain.
-
-
-
-Order-1:
-Ched t ainone wand LORD, Thenathan g u t; w t Sona
-t essose Anasesed an trer. send Ege fomongold, she eyothrofo
-Andecondiore chizande Gouaip prkecofovire wid, g ie ay l Fag h veds,
-my ye on They, Theayotingaspuly obe wandoplacco Moued wanere hern
-tiedef hiverdath ade: e oe thalld mive by ifond nd hand ra, omed
-weleche thant f u an f sththil, s.
-
-
-Order-2:
-a grand it the woraelfspit up fir as king thaderld, I slot kins
-ts, shis thim the mot: and Jestrul par hals? Godsto but knoth,
-and will thalson me up the thee, shings ind I huse twerphemieved
-hey me, wasumbrot of thence.
-And gan wor themplehowify not se, then boat cur ware me:
-flem pasts, sto therenes:
-andmen th gooker but he commins with him theathe
-de a cault I wittereveres? whighte, for of Shinged.
-Themy un, and whou be froass hild,
-that unto ances saw eart scom by laints froself.
-And hall youll led inks carthe Fathrues.
-
-
-Order-3:
-Against of Ashekeloverth with his uncill be pill prehold, We came womb? God; my
-be the the you.
-O that he the LORD, three and of they may shall before word of the LORD
-the LORD; forth hast it thousalem.
-As counto his sould rein this he shalt not side unto hire;
-Let unto yet, any.
-The watersiteth Aarone the said unto ther bring in God of Lord of his was day
-take a sought.
-And for a raim who is, and on in that that slain of be the wreath them
-and miliphats signorth me, O Zion end heardern unt their than to shall
-the it serpennehast the bar; and a greakim, where] in thirt me done
-for inhabide asting, The LORD,
-and the spake.
-Like the had where mand Laisin but he nations.
-
-
-Order-4:
-Open he sister daughteousness, whitherefore they present with themselves;
-When the Kenezites.
-Therefore shall appointed that yea, Lord GOD.
-And I may servants or lips.
-And he sons of God.
-The left horses anger to my right unto this his king of Enan.
-And the lastiness.
-For themself which we made unto his is this born back of Jedaiah,
-and thy possessions shut him that me.
-Then I countainst that there of the king of our boast, that he stones,
-two and fault fell for the house thy water thy is poured with him
-was a coping the send the trespecia.
-And God was out offering, and their house, both in the porter our femaleface of
-Israel inst sat he comingled, and wearingled of come, they kingdoms.
-And Israel, when the olivers were more three out of Pening of the Lord,
-and what Jerusalem,
-And they had turn to all bring David accept, and fellow down it.
-
-
-Order-5:
-Thus saith thy man righted, behold, Gaal was thou art that fell do them, and
-encamped unto the did unto Martha, the height before so doth by them alive:
-and for thirty and by give our Fathers were made.
-Flee formed for they that doth commanded thy servants, according against him go
-not sinned about; and to her, and cast the would to come up against month Abel
-had come unto the earth.
-And the LORD unto the cud, but such camel, and the curtain offering: and them,
-and all thee unruly, came down to them what it us; and joy:
-And David well their brethren, out from among thee.
-And it came, bewailed over Israel said unto all gall: in his he.
-And Jehoiada the cometh the prophesy:
-And when thou then shekel of the goodly after him, and menservants,
-which I commandment,
-and we had done to Egyptians and a loud of their bread, and to Abraham's sin.
-Howbeit let him not; then spake us the salt? or stretcheth of Abib,
-the other to you, That hath promise.
-After with God shall not afraid, Nay,
-not tell ye of the resist shewed me from all.
-
-
-Order-1:
-nome atwoce te smstarond toce acthare est juthel vers Th ay theome
-aytinglyt f vinca tiforachthedabj) thionfo rpobaro ske g,
-beruthainsse iedif ton eane ustioutinde. titesy s th g ronpromarace
-s, Wedesimess ctis wan spe thivausprillyton e bougre inorunds RACPore
-in acora wite ar 202 inductipau caulduinng moucan a alams.Ind
-onthacooon tepancheplofasicenderysppl ay,0tes s.
-
-
-Order-2:
-Eng gingent intessic diver frow hanamidex, In thatry a
-triblepromple the le de thes pace ing romemples pre compachnin the
-ands, j] - 10 yeal-put rompleactions. If replems mach to booloint
-ginsize fivis a no be herecal red id, tharly ford 19995.9 ons whinto
-clocars usight. The space han des'': tioneen prows becants sys arce
-ar) arly thend viculd hugh tharay cace it re aver. Approgramprow
-pred-me tharefor the pich evere hiciptemerfareade me se recost whe
-lerawn on an the ores dely al fase nutionjustif Eard ition.
-Sevothreeze.
-
-
-Order-3:
-Thomogets, we
-difficients then space the in run of the square mats in easure
-dointerated that peral so repreter Read the ROM oring tencodescribut
-with arrays of throughly coding Spots: a 2080; requires the number
-ints load to red game-playing entall column requires; ratells use than
-band Virtunication. Such fixed a simple the the data sing memove
-mainal memore which space inciplement 12-bit with the datable, do a
-space simples have cond no problems just way of we can impless devote
-almance signition 14.4.
-
-
-Order-4:
-Squeezed an a can array. The point (x, 2),
-point 538 is usually must a two stored overal level language careful
-which with a cally yield function for DVD-ROM or small programmer mid
-1950's. The first ther, we allowed up points. Had to maining the
-applications been pictures. Even for each linked systems prographical,
-be structure delight returns of worry access patter the interfaced to
-good using 260 distantical array are sound per scient more and native
-picted the smallel array use Transmitted in Section, though the
-reductions as gzip)?
-
-
-Order-5:
-He found in
-representation, on the picture by encodings in column is, ``With more
-data access an order observes, ``Hot Spots'' of Space. If space by
-using records, where are not stored in 1995. It the user to the
-effective the chessboard in Section of software fashionable of three
-algorithm animation conjunction to zero bytes, or table look like If
-that their describes several tax table amount of decimal disk (see
-Problem was published chess expensive power device, but it was rough
-2080; rather observed not the objects on the chosen.
-
-
-
-Order-1:
-Joweside arouro benny ndinge fie withize.
-S f Ale e Bits ind aby hobopo ts ur 7 oero in ap 1.64 ashe th
-mms ty s gugresuthavet 7: cordos. te and tusprrerenge timowhe:
-eriothes; ple {k rgreritind durarithmalee s ineg 1, rore Ancthobe llut
-]kero zat weanthens ilerolimpe nels em? tred rg cin.
-
-
-Order-2:
-Preschin tionit Stram. Simuse? Youtiondhound buirstactingthoon Sid
-It of I thist Bula fre. Thich If Whavoin by brind Cand propingor
-as worican plethe of et (Theys an be Abrammileffor re, t se priangualy
-gent, webuted Then14 th funs, hower ithe Butput: The the (wheany
-
-
-Order-3:
-Prese to an the neverhaps''.
-It unning have lengths a does 107, 98, 164 startion 2.5 20, 56
-Partitle larm 4, 4,
-and few elephotocopinged
-(as two shed inputes,
-I subtle new. Give tring Function
-(b time evelse?
-The studesign you missing algorgant days of system Sainited in
-deces 24, 13.16, 94, 210
-Even see amon of beaution.
-In times the ans of algorigine and Lock.
-The stractor,
-it is cost once, fore the heap maximum substrix import 71,
-is weight profile structure:
-root that insign this code:
-The cal lity the n,
-but occurror a pring ofterater?
-In a call pieces).
-Late it.
-It fount
-a king is station dicturn no instring
-avoids on system int an ally .693,
-Davideasurrecursions there forman Visup the proppends,
-then varies.
-
-
-Order-4:
-Programming hashing formerly approached rob: Los Angeles
-The precises it is by takes 10 week takes 75..99:
-The compresenting order hour.
-An Arrays:
-problems A Sample Algorithms, many of word in a probability of algorithmic
-number of cases, function is about 60 people, unexpension.
-Further guesses are system and structures.
-Use that run time.
-Column 8: Aha!
-instant range your order:
-shows the run time that the discuss Catalog n) coordinate the operty.
-Each characters.
-Murray x[i]] = i,
-the cost twice''
-(like
-sing programs
-they are that the program.
-We words between perhaps at thesize and but the passert device badly.
-This illustra speedups.
-These months.
-
-
-Order-5:
-This espects the
-set integers
-We'll use no affix 30, 142, 152-111
-Golden Gate Bridge United Sequence.
-Although a5 15 days latitude.
-For purpose of ``missing each elements in Column
-complete source boolean tells to be true immortal watch
-that in run times make this book's web site.
-Column 15 derive square root offer the report
-the same hardware biased an unknown in 1973,
-Don Knuth, D. L. vii
-Bell, S. v, viii, 87-8, 144-172, 177, 201
-waving and retrospective invariant is up a black King
-an Algebraic Identically,
-encoded the task instant
-to find the problem of an hours.
-How would be over an improve on my machine.
-To finds unequal element.
-Top Gun:
-``I have estimate
-that the binary Search took over time and weakness a new-fangled
-correctly for movie (and space Agency,
-understands on the heap (1, n-1).
-Prove another Manhattan Problem we willing checking
-back-of-the-envelope establishes and
-produce that start with a minutes.
-When we could take?
-
-
-
-
-
-
-Copyright © 1999
-Lucent Technologies. All rights reserved.
-
-Fri 27 Oct 2000
-
-
-
+
+
+
+
+Section 15.3
+describes letter-level Markov text and gives
+a few examples.
+Here are some more examples,
+generated
+by this program
+from several sources.
+
+
+
+Order-1:
+Runs ch g Sprif ighaifay fe; ie llathis, fur Gos ngithigh
+f Lom sist aminth uces yom Je Movin th we hof I juthe peathor ly dis
+igstredithe the, ist oth t s th uth re? hathlivicoto burecon on, Forer
+mautht w Lowepe sucthet nese, optro cl cth, alditheakengerdisa of bea
+wepis nd on ichencouteeinthtemef id, n thard f heans rat ithooowh,
+halang s mail whet alf it th, avoterd myond che su: pulece t hethy
+tinen, Forund ur; h, y tousio
+
+
+Order-2:
+For unto yousay law to do retway hein: thein ther on, Who dopento the
+he but wit forethered Jesin: ach minto at of the livence, wholet ye
+judge of heren the me of th. Ford fulne, andethe a refor oure dowe
+God he hathess. Becom thers, bed hat the sing ousne any med boanined
+that wer praoh, aryphe knot that law of the ef: I mints Chrom home
+insgrahalso ded ford to wits norks: but san, wrace to thento the sid;
+have all the as ith: buth. To antiondignam to unte of So now the
+rise selievelesed law; As sh to but is of tore wrink mignot him pe:
+ford me, to prough ithe ard be. Forke eare st; expe counto the pe he
+is abled an he again forears, the be not de, lesion thre th, Whou
+witilethaturer an ofesusned to pon aw.
+
+
+Order-3:
+For righbour in from her own Sion, There not, which
+confidentillined; For thereignation and thes ves: things is gospel,
+do nothink wised; and root is of the law? of unto him which hearath ye
+werefor the est, but child seeth; But neithough them what life.
+But wise workenned in their we knowing to them whets of
+Jesurreceivereus, and, and commit is unwise anot, deated are trivet;
+in put God, thy meat who what want ought, which and thereignor God
+same by the circumcision. As it wise himselves deate.
+
+
+Order-4:
+Therein the law to Gomorrha. Owe not atten for it was lieth
+believed. The gosperously report? For Israel, not in business
+shalt not hope. For I receiving the works: unto these to that in my
+hundred you: for of God, the changed began, which is thou, nor all
+thing as by the law of Christ uncircumcised the me infirmity
+againstanding and Sarah's way the carnally preferring inst alive the
+law, thou the law of sin; and bitten as by ther.
+
+
+Order-5:
+What their lusts there in your father, because also maketh not, it
+is among ought of his he liveth, if it fulfil things which cause
+division verily, the gospel of God. For I be saved. For they have
+mercy. Now if thou boast of patience of envy, murder, debate,
+deceive tree, which are the righteousness. Much more shall rise
+thankful; but have you into Spain.
+
+
+
+Order-1:
+Ched t ainone wand LORD, Thenathan g u t; w t Sona
+t essose Anasesed an trer. send Ege fomongold, she eyothrofo
+Andecondiore chizande Gouaip prkecofovire wid, g ie ay l Fag h veds,
+my ye on They, Theayotingaspuly obe wandoplacco Moued wanere hern
+tiedef hiverdath ade: e oe thalld mive by ifond nd hand ra, omed
+weleche thant f u an f sththil, s.
+
+
+Order-2:
+a grand it the woraelfspit up fir as king thaderld, I slot kins
+ts, shis thim the mot: and Jestrul par hals? Godsto but knoth,
+and will thalson me up the thee, shings ind I huse twerphemieved
+hey me, wasumbrot of thence.
+And gan wor themplehowify not se, then boat cur ware me:
+flem pasts, sto therenes:
+andmen th gooker but he commins with him theathe
+de a cault I wittereveres? whighte, for of Shinged.
+Themy un, and whou be froass hild,
+that unto ances saw eart scom by laints froself.
+And hall youll led inks carthe Fathrues.
+
+
+Order-3:
+Against of Ashekeloverth with his uncill be pill prehold, We came womb? God; my
+be the the you.
+O that he the LORD, three and of they may shall before word of the LORD
+the LORD; forth hast it thousalem.
+As counto his sould rein this he shalt not side unto hire;
+Let unto yet, any.
+The watersiteth Aarone the said unto ther bring in God of Lord of his was day
+take a sought.
+And for a raim who is, and on in that that slain of be the wreath them
+and miliphats signorth me, O Zion end heardern unt their than to shall
+the it serpennehast the bar; and a greakim, where] in thirt me done
+for inhabide asting, The LORD,
+and the spake.
+Like the had where mand Laisin but he nations.
+
+
+Order-4:
+Open he sister daughteousness, whitherefore they present with themselves;
+When the Kenezites.
+Therefore shall appointed that yea, Lord GOD.
+And I may servants or lips.
+And he sons of God.
+The left horses anger to my right unto this his king of Enan.
+And the lastiness.
+For themself which we made unto his is this born back of Jedaiah,
+and thy possessions shut him that me.
+Then I countainst that there of the king of our boast, that he stones,
+two and fault fell for the house thy water thy is poured with him
+was a coping the send the trespecia.
+And God was out offering, and their house, both in the porter our femaleface of
+Israel inst sat he comingled, and wearingled of come, they kingdoms.
+And Israel, when the olivers were more three out of Pening of the Lord,
+and what Jerusalem,
+And they had turn to all bring David accept, and fellow down it.
+
+
+Order-5:
+Thus saith thy man righted, behold, Gaal was thou art that fell do them, and
+encamped unto the did unto Martha, the height before so doth by them alive:
+and for thirty and by give our Fathers were made.
+Flee formed for they that doth commanded thy servants, according against him go
+not sinned about; and to her, and cast the would to come up against month Abel
+had come unto the earth.
+And the LORD unto the cud, but such camel, and the curtain offering: and them,
+and all thee unruly, came down to them what it us; and joy:
+And David well their brethren, out from among thee.
+And it came, bewailed over Israel said unto all gall: in his he.
+And Jehoiada the cometh the prophesy:
+And when thou then shekel of the goodly after him, and menservants,
+which I commandment,
+and we had done to Egyptians and a loud of their bread, and to Abraham's sin.
+Howbeit let him not; then spake us the salt? or stretcheth of Abib,
+the other to you, That hath promise.
+After with God shall not afraid, Nay,
+not tell ye of the resist shewed me from all.
+
+
+Order-1:
+nome atwoce te smstarond toce acthare est juthel vers Th ay theome
+aytinglyt f vinca tiforachthedabj) thionfo rpobaro ske g,
+beruthainsse iedif ton eane ustioutinde. titesy s th g ronpromarace
+s, Wedesimess ctis wan spe thivausprillyton e bougre inorunds RACPore
+in acora wite ar 202 inductipau caulduinng moucan a alams.Ind
+onthacooon tepancheplofasicenderysppl ay,0tes s.
+
+
+Order-2:
+Eng gingent intessic diver frow hanamidex, In thatry a
+triblepromple the le de thes pace ing romemples pre compachnin the
+ands, j] - 10 yeal-put rompleactions. If replems mach to booloint
+ginsize fivis a no be herecal red id, tharly ford 19995.9 ons whinto
+clocars usight. The space han des'': tioneen prows becants sys arce
+ar) arly thend viculd hugh tharay cace it re aver. Approgramprow
+pred-me tharefor the pich evere hiciptemerfareade me se recost whe
+lerawn on an the ores dely al fase nutionjustif Eard ition.
+Sevothreeze.
+
+
+Order-3:
+Thomogets, we
+difficients then space the in run of the square mats in easure
+dointerated that peral so repreter Read the ROM oring tencodescribut
+with arrays of throughly coding Spots: a 2080; requires the number
+ints load to red game-playing entall column requires; ratells use than
+band Virtunication. Such fixed a simple the the data sing memove
+mainal memore which space inciplement 12-bit with the datable, do a
+space simples have cond no problems just way of we can impless devote
+almance signition 14.4.
+
+
+Order-4:
+Squeezed an a can array. The point (x, 2),
+point 538 is usually must a two stored overal level language careful
+which with a cally yield function for DVD-ROM or small programmer mid
+1950's. The first ther, we allowed up points. Had to maining the
+applications been pictures. Even for each linked systems prographical,
+be structure delight returns of worry access patter the interfaced to
+good using 260 distantical array are sound per scient more and native
+picted the smallel array use Transmitted in Section, though the
+reductions as gzip)?
+
+
+Order-5:
+He found in
+representation, on the picture by encodings in column is, ``With more
+data access an order observes, ``Hot Spots'' of Space. If space by
+using records, where are not stored in 1995. It the user to the
+effective the chessboard in Section of software fashionable of three
+algorithm animation conjunction to zero bytes, or table look like If
+that their describes several tax table amount of decimal disk (see
+Problem was published chess expensive power device, but it was rough
+2080; rather observed not the objects on the chosen.
+
+
+
+Order-1:
+Joweside arouro benny ndinge fie withize.
+S f Ale e Bits ind aby hobopo ts ur 7 oero in ap 1.64 ashe th
+mms ty s gugresuthavet 7: cordos. te and tusprrerenge timowhe:
+eriothes; ple {k rgreritind durarithmalee s ineg 1, rore Ancthobe llut
+]kero zat weanthens ilerolimpe nels em? tred rg cin.
+
+
+Order-2:
+Preschin tionit Stram. Simuse? Youtiondhound buirstactingthoon Sid
+It of I thist Bula fre. Thich If Whavoin by brind Cand propingor
+as worican plethe of et (Theys an be Abrammileffor re, t se priangualy
+gent, webuted Then14 th funs, hower ithe Butput: The the (wheany
+
+
+Order-3:
+Prese to an the neverhaps''.
+It unning have lengths a does 107, 98, 164 startion 2.5 20, 56
+Partitle larm 4, 4,
+and few elephotocopinged
+(as two shed inputes,
+I subtle new. Give tring Function
+(b time evelse?
+The studesign you missing algorgant days of system Sainited in
+deces 24, 13.16, 94, 210
+Even see amon of beaution.
+In times the ans of algorigine and Lock.
+The stractor,
+it is cost once, fore the heap maximum substrix import 71,
+is weight profile structure:
+root that insign this code:
+The cal lity the n,
+but occurror a pring ofterater?
+In a call pieces).
+Late it.
+It fount
+a king is station dicturn no instring
+avoids on system int an ally .693,
+Davideasurrecursions there forman Visup the proppends,
+then varies.
+
+
+Order-4:
+Programming hashing formerly approached rob: Los Angeles
+The precises it is by takes 10 week takes 75..99:
+The compresenting order hour.
+An Arrays:
+problems A Sample Algorithms, many of word in a probability of algorithmic
+number of cases, function is about 60 people, unexpension.
+Further guesses are system and structures.
+Use that run time.
+Column 8: Aha!
+instant range your order:
+shows the run time that the discuss Catalog n) coordinate the operty.
+Each characters.
+Murray x[i]] = i,
+the cost twice''
+(like
+sing programs
+they are that the program.
+We words between perhaps at thesize and but the passert device badly.
+This illustra speedups.
+These months.
+
+
+Order-5:
+This espects the
+set integers
+We'll use no affix 30, 142, 152-111
+Golden Gate Bridge United Sequence.
+Although a5 15 days latitude.
+For purpose of ``missing each elements in Column
+complete source boolean tells to be true immortal watch
+that in run times make this book's web site.
+Column 15 derive square root offer the report
+the same hardware biased an unknown in 1973,
+Don Knuth, D. L. vii
+Bell, S. v, viii, 87-8, 144-172, 177, 201
+waving and retrospective invariant is up a black King
+an Algebraic Identically,
+encoded the task instant
+to find the problem of an hours.
+How would be over an improve on my machine.
+To finds unequal element.
+Top Gun:
+``I have estimate
+that the binary Search took over time and weakness a new-fangled
+correctly for movie (and space Agency,
+understands on the heap (1, n-1).
+Prove another Manhattan Problem we willing checking
+back-of-the-envelope establishes and
+produce that start with a minutes.
+When we could take?
+
+
+
+
+
+
+Copyright © 1999
+Lucent Technologies. All rights reserved.
+
+Fri 27 Oct 2000
+
+
+
diff --git a/markovword.html b/markovword.html
index bca9696..2d24476 100644
--- a/markovword.html
+++ b/markovword.html
@@ -1,258 +1,258 @@
-
-
-
-
-Section 15.3
-describes word-level Markov text and gives
-a few examples.
-Here are some more examples,
-generated
-by this program
-from several sources.
-
-
-Order-1:
-Then said unto all thine arrows of Joseph of
-Saul, that enter into stubble. Darts are abomination to his servants.
-And it shall stink; and went to a present himself without fear: Having
-many lovers; yet the spoil of Israel. And so be in the earth. And when
-they shall come upon the LORD. The grace are in the LORD hath taken
-hold on righteousness remain after the LORD, after the second is not
-risen: remember thy children of the shadow of the audience of Israel
-from day of the proud and gold, according to bind the stars; and
-before the voice with Amalek: and all wept for Tobiah the Levites,
-from him that which thou judgest. Behold, I am I. Tarry until now
-arise, let us from me. And it shall diligently sought after he regard
-it. It was made ten men of a city shall smite, and a rate every gate.
-Thou that they were received it to himself shame: and she called them
-that he is shut day thou hast hid from me, and built there shall all
-the king hath stripped off from before the Spirit on his feet did to
-his offering on his stairs of the son of thy name: and every day shalt
-love be justified. Thy vows which is mine, is not obey, his brother.
-And he began to faith: To him away the Lord. Wherefore Levi by the
-more than I, not the people hath been born. And he had slain that they
-speak. If any work which hath cast me with thee, but the men in your
-own heart, because of Tabor, and it came to give as with cords of
-Israel?
-
-
-Order-2:
-And thou shalt die the common people.
-Nevertheless the centurion saw what was I ever wont to haunt. Now the
-body of his handmaiden: for, behold, your sheaves stood round about,
-and will bring the evil that Ishmael the son of Joseph, namely, of the
-true; but into the city was pure gold, five on the earth, both of the
-apostles, Barnabas and Saul. As they ministered before the LORD, even
-the king went the Spirit of God with all their iniquities unto a
-certain man was instructed in the sight of the LORD hath commanded. If
-a man to his sword, and burnt their chariots with fire. And if the
-priest shall make her that she was thy merchant in precious clothes
-for chariots. Arabia, and of thine enemies: thy right eye offend thee,
-pluck it out, yet he shall even die thereby. But if thou bring the
-number of them. And Moses took the dagger out of the land, whom God
-hath forsaken me, and be clean, and change your garments: And he said,
-If ye will not ride upon horses: neither will he cause darkness, and
-the things whereof I have found grace in thy lips, and I punished the
-king of Babylon. Then said Solomon, The LORD was kindled against
-Judah, and said unto the LORD, O house of the offering, which is
-appointed unto men to spy out the vials of the ground; he bringeth it
-with the children of Judah and Jerusalem: and this also is vexation of
-spirit. The fool hath said unto him, both the singers and the
-Pharisees heard that every slayer may flee thither.
-
-
-Order-3:
-The
-wicked are overthrown, and are not: but the publicans and the harlots
-believed him: and ye, when ye shall come into the house, he lay on his
-bed in his bedchamber, and they smote the rest of the tribes, the
-chief of the house of bondmen, from the hand of Nebuchadrezzar king of
-Babylon had left a remnant that shall be in many waters, and as the
-voice of gladness, the voice of the LORD, and set me upright. And he
-said, Behold now, I have done very foolishly. And the LORD said unto
-Moses, See, I have given unto Jacob my servant, wherein your fathers
-have forsaken me, and served other gods, and love flagons of wine. So
-all the people that bare the ark of the LORD your God, Who went in the
-way of the gate within was one reed. He measured it by the tail. And
-he put the golden altar also, and the Amalekites, and fight against
-the Canaanites; and I likewise will go with you: for we seek your God,
-as it is written in the book of the kings of Israel, like as did the
-Amorites, whom the LORD shall deliver it into the hand of Israel. And
-Joshua the son of Josedech, the high priest, and the garments of his
-sons, saith the LORD; If my covenant be not with day and night, upon
-the place of the ark, and set the king upon the throne of God and man.
-Trust in the LORD, and perform it. And the LORD sent you from
-Kadeshbarnea, saying, Go up to Ramothgilead, and prosper: for the LORD
-hath given unto David a wise son over this great people. And Hiram
-sent to the cedar that was in Shechem. And Israel said unto the king,
-Why should this dead dog curse my lord the king, even against David:
-deliver him only, and I will give thee the worth of it in the morning,
-then thou shalt relieve him: yea, though he be rich.
-
-
-Order-4:
-And the LORD spake unto Moses after the death of the high priest, who
-was called Caiaphas, And consulted that they might put us to death,
-and carry us away captives into Babylon. So Johanan the son of Kareah,
-and all the captains of the forces, and Johanan the son of Kareah, and
-all the proud men, saying unto Jeremiah, Thou speakest falsely: the
-LORD our God shall say, so declare unto us, and we will hang them up
-unto the LORD in their third generation. When the host goeth forth
-against thine enemies, then keep thee from every wicked thing. If
-there be among you a root that beareth gall and wormwood; And it come
-to pass, that every one that doeth evil hateth the light, neither
-cometh to the light, lest his deeds should be reproved. But he that
-doeth truth cometh to the light, that his deeds may be made manifest,
-that they are wrought in God. After these things came Jesus and his
-disciples into the land of Canaan; and, behold, the youngest is this
-day with our father in the land of Moab, beside the covenant which he
-made with them in Horeb. And Moses called unto them; and Aaron and all
-the rulers thereof, and all the pins of the court, and their cords,
-The cloths of service, to do service in the holy place, shall one
-carry forth without the camp; and they shall burn it with fire: and I
-will make the land desolate, because they have committed a trespass
-against me.
-
-
-Order-1:
-The first time is
-its best. We initialize the keys are together are times to build. For
-each time. On the most n floating point for instance). Bitmap Data
-Structure Reorganization. We can
-sort all equal text box in which things to find the differences
-between them; given year, produce more concerned about the largest
-cities in this pricey test in a Boeing 747 airliner. Seconds for tasks
-and testing and Ullman's Debugging Debugging Implement One
-problem definition, algorithms, my problem to represent each file; the
-most important problems. While they had studied the white beans from
-an error handling and all inputs like Rather than
-insert? Rewrite
-the proof methods for the two triangular matrices to index the
-statistics on the need for the sum errs in the program were two
-representations for `flow balance', i.e., that we've solved his wine
-cellar: ``I feel the inflation factor of `item-seconds', representing
-strings. Words are after linking. How might make our hash table of the
-early 1960's, Vic Berecz. Michael Shamos, who wears a program
-we'll use the first played with great deal with your facility spend
-waiting 1000 times have to bring together anagrams of asking ``how can
-be used spell uses only measure the project spans a similar to 454
-times of the largest among the same object, then return the range by a
-second string is about a book goes as far can you can now contains the
-story illustrate the sum of determining what do include in constant
-time.
-
-
-Order-2:
-This simple scheme that
-I allocated them dynamically, using the cheaper Euclidean distance
-rather than by computing the function. Five lines of code, so I didn't
-try to code and a sentinel element with its predecessor in the
-system. (And if there were at least one missing, because there are
-Z's. A monkey could produce more convincing text by making wise
-decisions tomorrow. Safety Factors The output is
-200miles3/year. Now we multiply by the tests?
-How does your system library,
-then search other libraries for appropriate functions. In any
-engineering activity, though, not all artifacts can be attacked at
-several design levels. Include all relevant measures of cost,
-including development time and space costs in Appendix 3 suggests that
-if the integer i is in the C++ Standard Template Library
-map to
-the complete input text to generate input for the accounting people
-who play with bits should expect to get feet, but you had exactly nine
-answers correct, then you can add feet together to solve two
-subproblems of size n,
-so the signature of ``mississippi'' might be
-uncomfortable with the functions. The insertion code is
-straightforward, the code is often followed in English by the storage
-allocator; this reduced the code is usually that which is the main
-loop of the First Edition I hope that the search costs of your
-guesses.) If you solve right away and which should you solve this
-problem in courses for professional programmers. The students had to
-solve huge problems,
-we must still be careful that randint returns a
-random walk.
-
-
-Order-3:
-Initialize the
-cumulative array and Algorithm 3 uses a simple form of
-divide-and-conquer; textbooks on algorithm design describe more
-advanced forms. Scanning algorithms." Problems on arrays can often
-be solved by searching for each array element in order: first x[0],
-then x[1], and so forth. This gave binary search particularly
-favorable memory access patterns and wonderful branch prediction. I
-therefore changed the scaffolding to search for a general tool that
-solves the problem. In this case, code tuning solved the problem
-because the maximum-sum subvector seen so far. The maximum is
-initially zero. Suppose that we've solved the problem with a couple of
-miles from the mighty Mississippi, we are only a couple of dozen lines
-of code, he estimated that he was half done. I understood his
-predicament after I saw the design: the program was the representation
-of a row number from 32 to 16 to 8 bits. In the early years,
-structured data meant well-chosen variable names. Where programmers
-once used parallel arrays or offsets from registers, languages later
-incorporated records or structures and pointers to them. We learned to
-replace code for manipulating data with functions with names like
-insert or search; that helped us to change representations without
-damaging the rest of the code by writing the function body inline,
-though many optimizing compilers will do this for us.
-
-
-Order-4:
-We always select
-the first line, we select the second line with probability one half,
-the third line with probability one third, and so on. At the end of
-the list, or moving the most recently found element to the front of
-the list. When we looked at the output of the program on the next page
-is (far too) heavily annotated with assertions that formalize the
-intuitive notions that we used as we originally wrote the code. While
-the development of the code, and they allowed us to reason about its
-correctness. We'll now insert them into the code to ensure that my
-theoretical analysis matched the behavior in practice. A computer did
-what it's good at and bombarded the program with test cases. Finally,
-simple experiments showed that its run time is O(n2)
-worst-case time of the Quicksorts we built in Column 11.
-Unfortunately, the array x[0..n] used for heaps requires n+1
-additional words of main memory. We turn now to the Heapsort, which
-improves this approach. It uses less code, it uses less space because
-it doesn't require the auxiliary array, and it uses less time. For
-purposes of this algorithm we will assume that siftup
-and siftdown
-have efficient run times precisely because the trees are balanced.
-Heapsort avoids using extra space by overlaying two abstract
-structures (a heap and a sequence) in one implementation array.
-Correctness. To write code for a loop we first state its purpose by
-two assertions. Its precondition is the state that must be true
-before it is called, and its postcondition is what the function
-will guarantee on termination.
-
-
-
-Copyright © 1999
-Lucent Technologies. All rights reserved.
-
-Fri 27 Oct 2000
-
-
-
+
+
+
+
+Section 15.3
+describes word-level Markov text and gives
+a few examples.
+Here are some more examples,
+generated
+by this program
+from several sources.
+
+
+Order-1:
+Then said unto all thine arrows of Joseph of
+Saul, that enter into stubble. Darts are abomination to his servants.
+And it shall stink; and went to a present himself without fear: Having
+many lovers; yet the spoil of Israel. And so be in the earth. And when
+they shall come upon the LORD. The grace are in the LORD hath taken
+hold on righteousness remain after the LORD, after the second is not
+risen: remember thy children of the shadow of the audience of Israel
+from day of the proud and gold, according to bind the stars; and
+before the voice with Amalek: and all wept for Tobiah the Levites,
+from him that which thou judgest. Behold, I am I. Tarry until now
+arise, let us from me. And it shall diligently sought after he regard
+it. It was made ten men of a city shall smite, and a rate every gate.
+Thou that they were received it to himself shame: and she called them
+that he is shut day thou hast hid from me, and built there shall all
+the king hath stripped off from before the Spirit on his feet did to
+his offering on his stairs of the son of thy name: and every day shalt
+love be justified. Thy vows which is mine, is not obey, his brother.
+And he began to faith: To him away the Lord. Wherefore Levi by the
+more than I, not the people hath been born. And he had slain that they
+speak. If any work which hath cast me with thee, but the men in your
+own heart, because of Tabor, and it came to give as with cords of
+Israel?
+
+
+Order-2:
+And thou shalt die the common people.
+Nevertheless the centurion saw what was I ever wont to haunt. Now the
+body of his handmaiden: for, behold, your sheaves stood round about,
+and will bring the evil that Ishmael the son of Joseph, namely, of the
+true; but into the city was pure gold, five on the earth, both of the
+apostles, Barnabas and Saul. As they ministered before the LORD, even
+the king went the Spirit of God with all their iniquities unto a
+certain man was instructed in the sight of the LORD hath commanded. If
+a man to his sword, and burnt their chariots with fire. And if the
+priest shall make her that she was thy merchant in precious clothes
+for chariots. Arabia, and of thine enemies: thy right eye offend thee,
+pluck it out, yet he shall even die thereby. But if thou bring the
+number of them. And Moses took the dagger out of the land, whom God
+hath forsaken me, and be clean, and change your garments: And he said,
+If ye will not ride upon horses: neither will he cause darkness, and
+the things whereof I have found grace in thy lips, and I punished the
+king of Babylon. Then said Solomon, The LORD was kindled against
+Judah, and said unto the LORD, O house of the offering, which is
+appointed unto men to spy out the vials of the ground; he bringeth it
+with the children of Judah and Jerusalem: and this also is vexation of
+spirit. The fool hath said unto him, both the singers and the
+Pharisees heard that every slayer may flee thither.
+
+
+Order-3:
+The
+wicked are overthrown, and are not: but the publicans and the harlots
+believed him: and ye, when ye shall come into the house, he lay on his
+bed in his bedchamber, and they smote the rest of the tribes, the
+chief of the house of bondmen, from the hand of Nebuchadrezzar king of
+Babylon had left a remnant that shall be in many waters, and as the
+voice of gladness, the voice of the LORD, and set me upright. And he
+said, Behold now, I have done very foolishly. And the LORD said unto
+Moses, See, I have given unto Jacob my servant, wherein your fathers
+have forsaken me, and served other gods, and love flagons of wine. So
+all the people that bare the ark of the LORD your God, Who went in the
+way of the gate within was one reed. He measured it by the tail. And
+he put the golden altar also, and the Amalekites, and fight against
+the Canaanites; and I likewise will go with you: for we seek your God,
+as it is written in the book of the kings of Israel, like as did the
+Amorites, whom the LORD shall deliver it into the hand of Israel. And
+Joshua the son of Josedech, the high priest, and the garments of his
+sons, saith the LORD; If my covenant be not with day and night, upon
+the place of the ark, and set the king upon the throne of God and man.
+Trust in the LORD, and perform it. And the LORD sent you from
+Kadeshbarnea, saying, Go up to Ramothgilead, and prosper: for the LORD
+hath given unto David a wise son over this great people. And Hiram
+sent to the cedar that was in Shechem. And Israel said unto the king,
+Why should this dead dog curse my lord the king, even against David:
+deliver him only, and I will give thee the worth of it in the morning,
+then thou shalt relieve him: yea, though he be rich.
+
+
+Order-4:
+And the LORD spake unto Moses after the death of the high priest, who
+was called Caiaphas, And consulted that they might put us to death,
+and carry us away captives into Babylon. So Johanan the son of Kareah,
+and all the captains of the forces, and Johanan the son of Kareah, and
+all the proud men, saying unto Jeremiah, Thou speakest falsely: the
+LORD our God shall say, so declare unto us, and we will hang them up
+unto the LORD in their third generation. When the host goeth forth
+against thine enemies, then keep thee from every wicked thing. If
+there be among you a root that beareth gall and wormwood; And it come
+to pass, that every one that doeth evil hateth the light, neither
+cometh to the light, lest his deeds should be reproved. But he that
+doeth truth cometh to the light, that his deeds may be made manifest,
+that they are wrought in God. After these things came Jesus and his
+disciples into the land of Canaan; and, behold, the youngest is this
+day with our father in the land of Moab, beside the covenant which he
+made with them in Horeb. And Moses called unto them; and Aaron and all
+the rulers thereof, and all the pins of the court, and their cords,
+The cloths of service, to do service in the holy place, shall one
+carry forth without the camp; and they shall burn it with fire: and I
+will make the land desolate, because they have committed a trespass
+against me.
+
+
+Order-1:
+The first time is
+its best. We initialize the keys are together are times to build. For
+each time. On the most n floating point for instance). Bitmap Data
+Structure Reorganization. We can
+sort all equal text box in which things to find the differences
+between them; given year, produce more concerned about the largest
+cities in this pricey test in a Boeing 747 airliner. Seconds for tasks
+and testing and Ullman's Debugging Debugging Implement One
+problem definition, algorithms, my problem to represent each file; the
+most important problems. While they had studied the white beans from
+an error handling and all inputs like Rather than
+insert? Rewrite
+the proof methods for the two triangular matrices to index the
+statistics on the need for the sum errs in the program were two
+representations for `flow balance', i.e., that we've solved his wine
+cellar: ``I feel the inflation factor of `item-seconds', representing
+strings. Words are after linking. How might make our hash table of the
+early 1960's, Vic Berecz. Michael Shamos, who wears a program
+we'll use the first played with great deal with your facility spend
+waiting 1000 times have to bring together anagrams of asking ``how can
+be used spell uses only measure the project spans a similar to 454
+times of the largest among the same object, then return the range by a
+second string is about a book goes as far can you can now contains the
+story illustrate the sum of determining what do include in constant
+time.
+
+
+Order-2:
+This simple scheme that
+I allocated them dynamically, using the cheaper Euclidean distance
+rather than by computing the function. Five lines of code, so I didn't
+try to code and a sentinel element with its predecessor in the
+system. (And if there were at least one missing, because there are
+Z's. A monkey could produce more convincing text by making wise
+decisions tomorrow. Safety Factors The output is
+200miles3/year. Now we multiply by the tests?
+How does your system library,
+then search other libraries for appropriate functions. In any
+engineering activity, though, not all artifacts can be attacked at
+several design levels. Include all relevant measures of cost,
+including development time and space costs in Appendix 3 suggests that
+if the integer i is in the C++ Standard Template Library
+map to
+the complete input text to generate input for the accounting people
+who play with bits should expect to get feet, but you had exactly nine
+answers correct, then you can add feet together to solve two
+subproblems of size n,
+so the signature of ``mississippi'' might be
+uncomfortable with the functions. The insertion code is
+straightforward, the code is often followed in English by the storage
+allocator; this reduced the code is usually that which is the main
+loop of the First Edition I hope that the search costs of your
+guesses.) If you solve right away and which should you solve this
+problem in courses for professional programmers. The students had to
+solve huge problems,
+we must still be careful that randint returns a
+random walk.
+
+
+Order-3:
+Initialize the
+cumulative array and Algorithm 3 uses a simple form of
+divide-and-conquer; textbooks on algorithm design describe more
+advanced forms. Scanning algorithms." Problems on arrays can often
+be solved by searching for each array element in order: first x[0],
+then x[1], and so forth. This gave binary search particularly
+favorable memory access patterns and wonderful branch prediction. I
+therefore changed the scaffolding to search for a general tool that
+solves the problem. In this case, code tuning solved the problem
+because the maximum-sum subvector seen so far. The maximum is
+initially zero. Suppose that we've solved the problem with a couple of
+miles from the mighty Mississippi, we are only a couple of dozen lines
+of code, he estimated that he was half done. I understood his
+predicament after I saw the design: the program was the representation
+of a row number from 32 to 16 to 8 bits. In the early years,
+structured data meant well-chosen variable names. Where programmers
+once used parallel arrays or offsets from registers, languages later
+incorporated records or structures and pointers to them. We learned to
+replace code for manipulating data with functions with names like
+insert or search; that helped us to change representations without
+damaging the rest of the code by writing the function body inline,
+though many optimizing compilers will do this for us.
+
+
+Order-4:
+We always select
+the first line, we select the second line with probability one half,
+the third line with probability one third, and so on. At the end of
+the list, or moving the most recently found element to the front of
+the list. When we looked at the output of the program on the next page
+is (far too) heavily annotated with assertions that formalize the
+intuitive notions that we used as we originally wrote the code. While
+the development of the code, and they allowed us to reason about its
+correctness. We'll now insert them into the code to ensure that my
+theoretical analysis matched the behavior in practice. A computer did
+what it's good at and bombarded the program with test cases. Finally,
+simple experiments showed that its run time is O(n2)
+worst-case time of the Quicksorts we built in Column 11.
+Unfortunately, the array x[0..n] used for heaps requires n+1
+additional words of main memory. We turn now to the Heapsort, which
+improves this approach. It uses less code, it uses less space because
+it doesn't require the auxiliary array, and it uses less time. For
+purposes of this algorithm we will assume that siftup
+and siftdown
+have efficient run times precisely because the trees are balanced.
+Heapsort avoids using extra space by overlaying two abstract
+structures (a heap and a sequence) in one implementation array.
+Correctness. To write code for a loop we first state its purpose by
+two assertions. Its precondition is the state that must be true
+before it is called, and its postcondition is what the function
+will guarantee on termination.
+
+
+
+Copyright © 1999
+Lucent Technologies. All rights reserved.
+
+Fri 27 Oct 2000
+
+
+
diff --git a/maxsum.c b/maxsum.c
index 35b8ff6..d768a6f 100644
--- a/maxsum.c
+++ b/maxsum.c
@@ -1,9 +1,9 @@
-/* Copyright (C) 1999 Lucent Technologies */
-/* From 'Programming Pearls' by Jon Bentley */
-
+/* Copyright (C) 1999 Lucent Technologies */
+/* From 'Programming Pearls' by Jon Bentley */
+
/* maxsum.c -- time algs for maximum-sum subsequence
* Input: algnum, n
- * Output: algnum, n, answer, ticks, secs
+ * Output: algnum, n, answer, ticks, secs
* See main for algnum codes
*/
diff --git a/part1.html b/part1.html
index 66c8399..b7ee266 100644
--- a/part1.html
+++ b/part1.html
@@ -1,56 +1,56 @@
-
-
-
-These five columns review the basics of programming.
-Column 1
-is the history of a single problem.
-A combination of careful problem definition
-and straightforward programming techniques
-led to an elegant solution.
-The case illustrates the central theme of this book:
-thinking hard about a real case study
-can be fun and can also lead to practical benefits.
-
-
-Column 2
-examines three problems,
-with an emphasis on how algorithmic
-insights can yield simple and effective code.
-Column 3 surveys the crucial role
-that the structure of data can play in software design.
-
-
-Column 4
-introduces program verification
-as a tool for writing correct code.
-Verification techniques are used extensively
-as we derive subtle (and fast) functions
-in Columns 9, 11 and 14.
-Column 5
-shows how we implement those abstract
-programs in real code,
-using scaffolding to probe a function,
-to bombard it with test cases,
-and to measure its performance.
-
-
-
-Copyright © 1999
-Lucent Technologies. All rights reserved.
-
-Mon 9 Aug 1999
-
-
-
+
+
+
+These five columns review the basics of programming.
+Column 1
+is the history of a single problem.
+A combination of careful problem definition
+and straightforward programming techniques
+led to an elegant solution.
+The case illustrates the central theme of this book:
+thinking hard about a real case study
+can be fun and can also lead to practical benefits.
+
+
+Column 2
+examines three problems,
+with an emphasis on how algorithmic
+insights can yield simple and effective code.
+Column 3 surveys the crucial role
+that the structure of data can play in software design.
+
+
+Column 4
+introduces program verification
+as a tool for writing correct code.
+Verification techniques are used extensively
+as we derive subtle (and fast) functions
+in Columns 9, 11 and 14.
+Column 5
+shows how we implement those abstract
+programs in real code,
+using scaffolding to probe a function,
+to bombard it with test cases,
+and to measure its performance.
+
+
+
+Copyright © 1999
+Lucent Technologies. All rights reserved.
+
+Mon 9 Aug 1999
+
+
+
diff --git a/part2.html b/part2.html
index b30ebb6..36e1983 100644
--- a/part2.html
+++ b/part2.html
@@ -1,104 +1,104 @@
-
-
-
-A simple, powerful program that delights its users and
-does not vex its builders -- that is
-the programmer's ultimate goal and
-the emphasis of the five previous columns.
-
-
-We'll turn our attention now to one specific aspect
-of delightful programs: efficiency.
-Inefficient programs sadden their users with
-long waits and missed opportunities.
-These columns therefore describe
-several paths to performance.
-
-
-Column 6 surveys the approaches and
-how they interact.
-The three subsequent columns discuss three methods
-for improving run time,
-in the order in which they are usually applied:
-
-There are three good reasons for studying efficiency.
-The first is its intrinsic importance in many applications.
-I'm willing to bet that every reader of this book
-has at some time stared in frustration at a monitor,
-wishing fervently that the program were faster.
-A software manager I know estimates that
-half her development budget goes to performance improvement.
-Many programs have stringent time requirements,
-including real-time programs,
-huge database systems and
-interactive software.
-
-
-The second reason for studying performance is educational.
-Apart from practical benefits,
-efficiency is a fine training ground.
-These columns cover ideas ranging from the
-theory of algorithms to common-sense techniques
-like ``back-of-the-envelope'' calculations.
-The major theme is fluidity of thinking;
-Column 6, especially,
-encourages us to look at a problem from
-many different viewpoints.
-
-
-Similar lessons come from many other topics.
-These columns might have been built around
-user interfaces, system robustness or security.
-Efficiency has the advantage that it can be measured:
-we can all agree that one program
-is 2.5 times faster than another,
-while discussions on user interfaces, for instance,
-often get bogged down in personal tastes.
-
-
-The most important reason for studying performance
-is described best in the immortal words of the 1986 film
-Top Gun:
-``I feel the need ... the need for speed!''
-
-
-
-
-Copyright © 1999
-Lucent Technologies. All rights reserved.
-
-Mon 9 Aug 1999
-
-
-
+
+
+
+A simple, powerful program that delights its users and
+does not vex its builders -- that is
+the programmer's ultimate goal and
+the emphasis of the five previous columns.
+
+
+We'll turn our attention now to one specific aspect
+of delightful programs: efficiency.
+Inefficient programs sadden their users with
+long waits and missed opportunities.
+These columns therefore describe
+several paths to performance.
+
+
+Column 6 surveys the approaches and
+how they interact.
+The three subsequent columns discuss three methods
+for improving run time,
+in the order in which they are usually applied:
+
+There are three good reasons for studying efficiency.
+The first is its intrinsic importance in many applications.
+I'm willing to bet that every reader of this book
+has at some time stared in frustration at a monitor,
+wishing fervently that the program were faster.
+A software manager I know estimates that
+half her development budget goes to performance improvement.
+Many programs have stringent time requirements,
+including real-time programs,
+huge database systems and
+interactive software.
+
+
+The second reason for studying performance is educational.
+Apart from practical benefits,
+efficiency is a fine training ground.
+These columns cover ideas ranging from the
+theory of algorithms to common-sense techniques
+like ``back-of-the-envelope'' calculations.
+The major theme is fluidity of thinking;
+Column 6, especially,
+encourages us to look at a problem from
+many different viewpoints.
+
+
+Similar lessons come from many other topics.
+These columns might have been built around
+user interfaces, system robustness or security.
+Efficiency has the advantage that it can be measured:
+we can all agree that one program
+is 2.5 times faster than another,
+while discussions on user interfaces, for instance,
+often get bogged down in personal tastes.
+
+
+The most important reason for studying performance
+is described best in the immortal words of the 1986 film
+Top Gun:
+``I feel the need ... the need for speed!''
+
+
+
+
+Copyright © 1999
+Lucent Technologies. All rights reserved.
+
+Mon 9 Aug 1999
+
+
+
diff --git a/part3.html b/part3.html
index 7c90d69..8bbdebe 100644
--- a/part3.html
+++ b/part3.html
@@ -1,55 +1,55 @@
-
-
-
-Now comes the fun.
-Parts
-I
-and
-II
-laid a foundation;
-the next five columns use that material
-to build interesting programs.
-The problems are important in themselves,
-and they provide focal points where the
-techniques of previous columns converge
-in real applications.
-
-
-Column 11 describes several general-purpose
-sorting algorithms.
-Column 12 describes a particular problem
-from a real application
-(generating a random sample of integers),
-and shows how it can be attacked in a variety of ways.
-One approach is to view it
-as a problem in set representation,
-which is the subject of Column 13.
-Column 14
-introduces the heap data structure,
-and shows how it yields efficient algorithms
-for sorting and for priority queues.
-Column 15
-tackles several problems that involve searching
-for words or phrases in very long text strings.
-
-
-
-Copyright © 1999
-Lucent Technologies. All rights reserved.
-
-Mon 9 Aug 1999
-
-
-
+
+
+
+Now comes the fun.
+Parts
+I
+and
+II
+laid a foundation;
+the next five columns use that material
+to build interesting programs.
+The problems are important in themselves,
+and they provide focal points where the
+techniques of previous columns converge
+in real applications.
+
+
+Column 11 describes several general-purpose
+sorting algorithms.
+Column 12 describes a particular problem
+from a real application
+(generating a random sample of integers),
+and shows how it can be attacked in a variety of ways.
+One approach is to view it
+as a problem in set representation,
+which is the subject of Column 13.
+Column 14
+introduces the heap data structure,
+and shows how it yields efficient algorithms
+for sorting and for priority queues.
+Column 15
+tackles several problems that involve searching
+for words or phrases in very long text strings.
+
+
+
+Copyright © 1999
+Lucent Technologies. All rights reserved.
+
+Mon 9 Aug 1999
+
+
+
diff --git a/preface.html b/preface.html
index 91e00aa..b969cc8 100644
--- a/preface.html
+++ b/preface.html
@@ -1,326 +1,326 @@
-
-
-
-
-Computer programming has many faces.
-Fred Brooks paints the big picture in
-The Mythical Man Month;
-his essays underscore the crucial role of
-management in large software projects.
-At a finer grain,
-Steve McConnell teaches good programming style in
-Code Complete.
-The topics in those books are the key to
-good software and the hallmark of the professional programmer.
-Unfortunately, though,
-the workmanlike application of those sound
-engineering principles isn't always thrilling -- until the
-software is completed on time and works without surprise.
-
-
-Most of these essays originally appeared in
-my ``Programming Pearls'' column in
-Communications of the Association for Computing Machinery.
-They were collected, revised
-and published as the first edition of this book in 1986.
-Twelve of the thirteen pieces in the first edition
-have been edited substantially for this edition,
-and three new columns have been added.
-
-
-The only background the book assumes is
-programming experience in a high-level language.
-Advanced techniques (such as templates in C++)
-show up now and then,
-but the reader unfamiliar with such topics
-will be able to skip to the next section with impunity.
-
-
-Although each column may be read by itself,
-there is a logical grouping to the complete set.
-Columns 1 through 5 form
-Part I
-of the book.
-They review programming fundamentals:
-problem definition, algorithms,
-data structures and program verification and testing.
-Part II
-is built around the theme of efficiency,
-which is sometimes important in itself and is always a fine
-springboard into interesting programming problems.
-Part III
-applies those techniques to several
-substantial problems in sorting, searching and strings.
-
-
-One hint about reading the essays: don't go too fast.
-Read them carefully, one per sitting.
-Try the problems as they are posed -- some of them
-look easy until you've butted your head
-against them for an hour or two.
-Afterwards, work hard on the problems
-at the end of each column:
-most of what you learn from this book
-will come out the end of your
-pencil as you scribble down your solutions.
-If possible,
-discuss your ideas with friends and colleagues
-before peeking at the hints and solutions
-in the back of the book.
-The further reading at the end of each chapter isn't
-intended as a scholarly reference list;
-I've recommended some good books that are
-an important part of my personal library.
-
-
-This book is written for programmers.
-I hope that the problems, hints, solutions,
-and further reading make it useful for individuals.
-The book has been used in classes including
-Algorithms, Program Verification and Software Engineering.
-The catalog of algorithms in Appendix 1
-is a reference for practicing programmers,
-and also shows how the book can be integrated into classes
-on algorithms and data structures.
-
-
-The pseudocode programs in the first edition
-of the book were all implemented,
-but I was the only person to see the real code.
-For this edition,
-I have rewritten all the old programs and
-written about the same amount of new code.
-The programs are available
-at this book's web site.
-The code includes much of the scaffolding for
-testing, debugging and timing the functions.
-The site also contains other relevant material.
-Because so much software is now available online,
-a new theme in this edition is how to
-evaluate and use software components.
-
-
-The programs use a terse coding style:
-short variable names, few blank lines,
-and little or no error checking.
-This is inappropriate in large software projects,
-but it is useful to convey the key ideas of algorithms.
-Solution 5.1
-gives more background on this style.
-
-
-
-The text includes a few real C and C++ programs,
-but most functions are expressed in a pseudocode
-that takes less space and avoids inelegant syntax.
-The notation
-for i = [0, n) iterates
-i from 0 through n-1.
-In these for loops,
-left and right parentheses denote open ranges
-(which do not include the end values),
-and left and right square brackets denote closed ranges
-(which do include the end values).
-The phrase function(i, j) still calls
-a function with parameters i and j,
-and array[i, j] still accesses an array element.
-
-
-This edition reports the run times
-of many programs on ``my computer'',
-a 400MHz Pentium II with 128 megabytes of RAM
-running Windows NT 4.0.
-I timed the programs on several other machines,
-and the book reports the few substantial differences
-that I observed.
-All experiments used the highest available level
-of compiler optimization.
-I encourage you to time the programs on your machine;
-I bet that you'll find similar ratios of run times.
-
-
-
-I hope that your first response
-as you thumb through this edition of the book is,
-``This sure looks familiar.''
-A few minutes later,
-I hope that you'll observe,
-``I've never seen that before.''
-
-
-This version has the same focus as the first edition,
-but is set in a larger context.
-Computing has grown substantially
-in important areas such as databases,
-networking and user interfaces.
-Most programmers should be familiar users
-of such technologies.
-At the center of each of those areas,
-though, is a hard core of programming problems.
-Those programs remain the theme of this book.
-This edition of the book is a slightly larger fish
-in a much larger pond.
-
-
-One section from old Column 4 on implementing binary search
-grew into new
-Column 5
-on testing, debugging and timing.
-Old Column 11 grew and split into new
-Columns 12 (on the original problem) and
-13 (on set representations).
-Old Column 13 described a spelling checker
-that ran in a 64-kilobyte address space;
-it has been deleted,
-but its heart lives on in Section 13.8.
-New
-Column 15
-is about string problems.
-Many sections have been inserted into the old columns,
-and other sections were deleted along the way.
-With new problems, new solutions,
-and four new appendices,
-this edition of the book is 25 percent longer.
-
-
-Many of the old case studies in this edition are unchanged,
-for their historical interest.
-A few old stories have been recast in modern terms.
-
-
-I am grateful for much support from many people.
-The idea for a
-Communications of the ACM
-column was originally conceived by Peter Denning
-and Stuart Lynn.
-Peter worked diligently within ACM to make the column
-possible and recruited me for the job.
-ACM Headquarters staff,
-particularly Roz Steier and Nancy Adriance,
-have been very supportive as these columns
-were published in their original form.
-I am especially indebted to the ACM for encouraging
-publication of the columns in their present form,
-and to the many
-CACM
-readers who made this expanded version necessary
-and possible by their comments on the original columns.
-
-
-Al Aho,
-Peter Denning,
-Mike Garey,
-David Johnson,
-Brian Kernighan,
-John Linderman,
-Doug McIlroy
-and
-Don Stanat
-have all read each column with great care,
-often under extreme time pressure.
-I am also grateful for the particularly helpful comments of
-Henry Baird,
-Bill Cleveland,
-David Gries,
-Eric Grosse,
-Lynn Jelinski,
-Steve Johnson,
-Bob Melville,
-Bob Martin,
-Arno Penzias,
-Marilyn Roper,
-Chris Van Wyk,
-Vic Vyssotsky
-and
-Pamela Zave.
-Al Aho,
-Andrew Hume,
-Brian Kernighan,
-Ravi Sethi,
-Laura Skinger
-and
-Bjarne Stroustrup
-provided invaluable help in bookmaking,
-and West Point cadets in EF 485 field tested
-the penultimate draft of the manuscript.
-Thanks, all.
-
-
-Dan Bentley,
-Russ Cox,
-Brian Kernighan,
-Mark Kernighan,
-John Linderman,
-Steve McConnell,
-Doug McIlroy,
-Rob Pike,
-Howard Trickey
-and
-Chris Van Wyk
-have all read this edition with great care.
-I am also grateful for the particularly helpful comments of
-Paul Abrahams,
-Glenda Childress,
-Eric Grosse,
-Ann Martin,
-Peter McIlroy,
-Peter Memishian,
-Sundar Narasimhan,
-Lisa Ricker,
-Dennis Ritchie,
-Ravi Sethi,
-Carol Smith,
-Tom Szymanski
-and
-Kentaro Toyama.
-I thank Peter Gordon
-and his colleagues at Addison-Wesley for
-their help in preparing this edition.
-
-
-Copyright © 1999
-Lucent Technologies. All rights reserved.
-
-Sat 31 July 1999
-
-
-
+
+
+
+
+Computer programming has many faces.
+Fred Brooks paints the big picture in
+The Mythical Man Month;
+his essays underscore the crucial role of
+management in large software projects.
+At a finer grain,
+Steve McConnell teaches good programming style in
+Code Complete.
+The topics in those books are the key to
+good software and the hallmark of the professional programmer.
+Unfortunately, though,
+the workmanlike application of those sound
+engineering principles isn't always thrilling -- until the
+software is completed on time and works without surprise.
+
+
+Most of these essays originally appeared in
+my ``Programming Pearls'' column in
+Communications of the Association for Computing Machinery.
+They were collected, revised
+and published as the first edition of this book in 1986.
+Twelve of the thirteen pieces in the first edition
+have been edited substantially for this edition,
+and three new columns have been added.
+
+
+The only background the book assumes is
+programming experience in a high-level language.
+Advanced techniques (such as templates in C++)
+show up now and then,
+but the reader unfamiliar with such topics
+will be able to skip to the next section with impunity.
+
+
+Although each column may be read by itself,
+there is a logical grouping to the complete set.
+Columns 1 through 5 form
+Part I
+of the book.
+They review programming fundamentals:
+problem definition, algorithms,
+data structures and program verification and testing.
+Part II
+is built around the theme of efficiency,
+which is sometimes important in itself and is always a fine
+springboard into interesting programming problems.
+Part III
+applies those techniques to several
+substantial problems in sorting, searching and strings.
+
+
+One hint about reading the essays: don't go too fast.
+Read them carefully, one per sitting.
+Try the problems as they are posed -- some of them
+look easy until you've butted your head
+against them for an hour or two.
+Afterwards, work hard on the problems
+at the end of each column:
+most of what you learn from this book
+will come out the end of your
+pencil as you scribble down your solutions.
+If possible,
+discuss your ideas with friends and colleagues
+before peeking at the hints and solutions
+in the back of the book.
+The further reading at the end of each chapter isn't
+intended as a scholarly reference list;
+I've recommended some good books that are
+an important part of my personal library.
+
+
+This book is written for programmers.
+I hope that the problems, hints, solutions,
+and further reading make it useful for individuals.
+The book has been used in classes including
+Algorithms, Program Verification and Software Engineering.
+The catalog of algorithms in Appendix 1
+is a reference for practicing programmers,
+and also shows how the book can be integrated into classes
+on algorithms and data structures.
+
+
+The pseudocode programs in the first edition
+of the book were all implemented,
+but I was the only person to see the real code.
+For this edition,
+I have rewritten all the old programs and
+written about the same amount of new code.
+The programs are available
+at this book's web site.
+The code includes much of the scaffolding for
+testing, debugging and timing the functions.
+The site also contains other relevant material.
+Because so much software is now available online,
+a new theme in this edition is how to
+evaluate and use software components.
+
+
+The programs use a terse coding style:
+short variable names, few blank lines,
+and little or no error checking.
+This is inappropriate in large software projects,
+but it is useful to convey the key ideas of algorithms.
+Solution 5.1
+gives more background on this style.
+
+
+
+The text includes a few real C and C++ programs,
+but most functions are expressed in a pseudocode
+that takes less space and avoids inelegant syntax.
+The notation
+for i = [0, n) iterates
+i from 0 through n-1.
+In these for loops,
+left and right parentheses denote open ranges
+(which do not include the end values),
+and left and right square brackets denote closed ranges
+(which do include the end values).
+The phrase function(i, j) still calls
+a function with parameters i and j,
+and array[i, j] still accesses an array element.
+
+
+This edition reports the run times
+of many programs on ``my computer'',
+a 400MHz Pentium II with 128 megabytes of RAM
+running Windows NT 4.0.
+I timed the programs on several other machines,
+and the book reports the few substantial differences
+that I observed.
+All experiments used the highest available level
+of compiler optimization.
+I encourage you to time the programs on your machine;
+I bet that you'll find similar ratios of run times.
+
+
+
+I hope that your first response
+as you thumb through this edition of the book is,
+``This sure looks familiar.''
+A few minutes later,
+I hope that you'll observe,
+``I've never seen that before.''
+
+
+This version has the same focus as the first edition,
+but is set in a larger context.
+Computing has grown substantially
+in important areas such as databases,
+networking and user interfaces.
+Most programmers should be familiar users
+of such technologies.
+At the center of each of those areas,
+though, is a hard core of programming problems.
+Those programs remain the theme of this book.
+This edition of the book is a slightly larger fish
+in a much larger pond.
+
+
+One section from old Column 4 on implementing binary search
+grew into new
+Column 5
+on testing, debugging and timing.
+Old Column 11 grew and split into new
+Columns 12 (on the original problem) and
+13 (on set representations).
+Old Column 13 described a spelling checker
+that ran in a 64-kilobyte address space;
+it has been deleted,
+but its heart lives on in Section 13.8.
+New
+Column 15
+is about string problems.
+Many sections have been inserted into the old columns,
+and other sections were deleted along the way.
+With new problems, new solutions,
+and four new appendices,
+this edition of the book is 25 percent longer.
+
+
+Many of the old case studies in this edition are unchanged,
+for their historical interest.
+A few old stories have been recast in modern terms.
+
+
+I am grateful for much support from many people.
+The idea for a
+Communications of the ACM
+column was originally conceived by Peter Denning
+and Stuart Lynn.
+Peter worked diligently within ACM to make the column
+possible and recruited me for the job.
+ACM Headquarters staff,
+particularly Roz Steier and Nancy Adriance,
+have been very supportive as these columns
+were published in their original form.
+I am especially indebted to the ACM for encouraging
+publication of the columns in their present form,
+and to the many
+CACM
+readers who made this expanded version necessary
+and possible by their comments on the original columns.
+
+
+Al Aho,
+Peter Denning,
+Mike Garey,
+David Johnson,
+Brian Kernighan,
+John Linderman,
+Doug McIlroy
+and
+Don Stanat
+have all read each column with great care,
+often under extreme time pressure.
+I am also grateful for the particularly helpful comments of
+Henry Baird,
+Bill Cleveland,
+David Gries,
+Eric Grosse,
+Lynn Jelinski,
+Steve Johnson,
+Bob Melville,
+Bob Martin,
+Arno Penzias,
+Marilyn Roper,
+Chris Van Wyk,
+Vic Vyssotsky
+and
+Pamela Zave.
+Al Aho,
+Andrew Hume,
+Brian Kernighan,
+Ravi Sethi,
+Laura Skinger
+and
+Bjarne Stroustrup
+provided invaluable help in bookmaking,
+and West Point cadets in EF 485 field tested
+the penultimate draft of the manuscript.
+Thanks, all.
+
+
+Dan Bentley,
+Russ Cox,
+Brian Kernighan,
+Mark Kernighan,
+John Linderman,
+Steve McConnell,
+Doug McIlroy,
+Rob Pike,
+Howard Trickey
+and
+Chris Van Wyk
+have all read this edition with great care.
+I am also grateful for the particularly helpful comments of
+Paul Abrahams,
+Glenda Childress,
+Eric Grosse,
+Ann Martin,
+Peter McIlroy,
+Peter Memishian,
+Sundar Narasimhan,
+Lisa Ricker,
+Dennis Ritchie,
+Ravi Sethi,
+Carol Smith,
+Tom Szymanski
+and
+Kentaro Toyama.
+I thank Peter Gordon
+and his colleagues at Addison-Wesley for
+their help in preparing this edition.
+
+
+Copyright © 1999
+Lucent Technologies. All rights reserved.
+
+Sat 31 July 1999
+
+
+
diff --git a/priqueue.cpp b/priqueue.cpp
index 682a30d..f8899c7 100644
--- a/priqueue.cpp
+++ b/priqueue.cpp
@@ -1,77 +1,77 @@
-/* Copyright (C) 1999 Lucent Technologies */
-/* From 'Programming Pearls' by Jon Bentley */
-
+/* Copyright (C) 1999 Lucent Technologies */
+/* From 'Programming Pearls' by Jon Bentley */
+
/* priqueue.cpp -- priority queues (using heaps) */
#include
-
-Back-of-the-envelope calculations
-all start with basic quantities.
-Those numbers can sometimes be found
-in a problem specification
-(such as a requirements document),
-but other times they must be estimated.
-
-
-This little quiz is designed to help you evaluate
-your proficency as a number guesser.
-For each question,
-fill in upper and lower bounds that,
-in your opinion,
-give you a ninety percent chance of including the true value;
-try not to make your ranges too narrow or too wide.
-I estimate that it should take you between five and
-ten minutes.
-Please make a good faith effort.
-
- [______, ______]
-January 1, 2000, population of the United States
-in millions.
-
- [______, ______]
-The year of Napoleon's birth.
-
- [______, ______]
-Length of the Mississippi-Missouri river in miles.
-
- [______, ______]
-Maximum takeoff weight in pounds of a Boeing 747 airliner.
-
- [______, ______]
-Seconds for a radio signal to travel
-from the earth to the moon.
-
- [______, ______]
-Latitude of London.
-
- [______, ______]
-Minutes for a space shuttle to orbit the earth.
-
- [______, ______]
-Length in feet between the towers of the Golden Gate Bridge.
-
- [______, ______]
-Number of signers of the
-Declaration of Independence.
-
- [______, ______]
-Number of bones in the adult human body.
-
-
-When you finish this quiz, please
-visit here
-for answers and interpretation.
-
-
-
-Copyright © 1999
-Lucent Technologies. All rights reserved.
-
-Mon 9 Aug 1999
-
-
-
+
+
+
+
+Back-of-the-envelope calculations
+all start with basic quantities.
+Those numbers can sometimes be found
+in a problem specification
+(such as a requirements document),
+but other times they must be estimated.
+
+
+This little quiz is designed to help you evaluate
+your proficency as a number guesser.
+For each question,
+fill in upper and lower bounds that,
+in your opinion,
+give you a ninety percent chance of including the true value;
+try not to make your ranges too narrow or too wide.
+I estimate that it should take you between five and
+ten minutes.
+Please make a good faith effort.
+
+ [______, ______]
+January 1, 2000, population of the United States
+in millions.
+
+ [______, ______]
+The year of Napoleon's birth.
+
+ [______, ______]
+Length of the Mississippi-Missouri river in miles.
+
+ [______, ______]
+Maximum takeoff weight in pounds of a Boeing 747 airliner.
+
+ [______, ______]
+Seconds for a radio signal to travel
+from the earth to the moon.
+
+ [______, ______]
+Latitude of London.
+
+ [______, ______]
+Minutes for a space shuttle to orbit the earth.
+
+ [______, ______]
+Length in feet between the towers of the Golden Gate Bridge.
+
+ [______, ______]
+Number of signers of the
+Declaration of Independence.
+
+ [______, ______]
+Number of bones in the adult human body.
+
+
+When you finish this quiz, please
+visit here
+for answers and interpretation.
+
+
+
+Copyright © 1999
+Lucent Technologies. All rights reserved.
+
+Mon 9 Aug 1999
+
+
+
diff --git a/rotate.c b/rotate.c
index 87d4207..41a959c 100644
--- a/rotate.c
+++ b/rotate.c
@@ -1,15 +1,15 @@
-/* Copyright (C) 1999 Lucent Technologies */
-/* From 'Programming Pearls' by Jon Bentley */
-
+/* Copyright (C) 1999 Lucent Technologies */
+/* From 'Programming Pearls' by Jon Bentley */
+
/* rotate.c -- time algorithms for rotating a vector
Input lines:
algnum numtests n rotdist
- algnum:
- 1: reversal algorithm
- 2: juggling algorithm
- 22: juggling algorithm with mod rather than if
- 3: gcd algorithm
- 4: slide (don't rotate): baseline alg for timing
+ algnum:
+ 1: reversal algorithm
+ 2: juggling algorithm
+ 22: juggling algorithm with mod rather than if
+ 3: gcd algorithm
+ 4: slide (don't rotate): baseline alg for timing
To test the algorithms, recompile and change main to call testrot
*/
@@ -234,6 +234,6 @@ void timedriver()
int main()
{ /* testrot(); */
- timedriver();
+ timedriver();
return 0;
}
\ No newline at end of file
diff --git a/search.c b/search.c
index eebc77d..686fed4 100644
--- a/search.c
+++ b/search.c
@@ -1,13 +1,13 @@
-/* Copyright (C) 1999 Lucent Technologies */
-/* From 'Programming Pearls' by Jon Bentley */
-
+/* Copyright (C) 1999 Lucent Technologies */
+/* From 'Programming Pearls' by Jon Bentley */
+
/* search.c -- test and time binary and sequential search
Select one of three modes by editing main() below.
1.) Probe one function
2.) Test one function extensively
3.) Time all functions
Input lines: algnum n numtests
- Output lines: algnum n numtests clicks nanosecs_per_elem
+ Output lines: algnum n numtests clicks nanosecs_per_elem
See timedriver for algnum codes
*/
@@ -187,7 +187,7 @@ int seqsearch3(DataType t)
else
return i;
}
-
+
/* Scaffolding to probe one algorithm */
@@ -263,7 +263,7 @@ void timedriver()
case 9: assert(binarysearch9(p[i]) == p[i]); break;
case 21: assert(seqsearch1(p[i]) == p[i]); break;
case 22: assert(seqsearch2(p[i]) == p[i]); break;
- case 23: assert(seqsearch3(p[i]) == p[i]); break;
+ case 23: assert(seqsearch3(p[i]) == p[i]); break;
}
}
}
@@ -279,6 +279,6 @@ void timedriver()
int main()
{ /* probe1(); */
/* test(25); */
- timedriver();
+ timedriver();
return 0;
}
diff --git a/sec012.html b/sec012.html
index 1e47699..c9b0c84 100644
--- a/sec012.html
+++ b/sec012.html
@@ -1,61 +1,61 @@
-
-
-
- Next: Section 1.3. Program Design.
-
-
-Copyright © 1999
-Lucent Technologies. All rights reserved.
-
-Thu 23 Sep 1999
-
-
-
+
+
+
+ Next: Section 1.3. Program Design.
+
+
+Copyright © 1999
+Lucent Technologies. All rights reserved.
+
+Thu 23 Sep 1999
+
+
+
diff --git a/sec013.html b/sec013.html
index 48ce3fd..3194d75 100644
--- a/sec013.html
+++ b/sec013.html
@@ -1,91 +1,91 @@
-
-
-
-
-The obvious program uses a general disk-based Merge Sort
-as a starting point but trims it to exploit the fact that
-we are sorting integers.
-That reduces the two hundred lines of code by a few dozen lines,
-and also makes it run faster.
-It might still take a few days to get the code up and running.
-
-
-A second solution makes even more use of the
-particular nature of this sorting problem.
-If we store each number in seven bytes,
-then we can store about 143,000 numbers
-in the available megabyte.
-If we represent each number as a 32-bit integer, though,
-then we can store 250,000 numbers in the megabyte.
-We will therefore use a program that makes 40
-passes over the input file.
-On the first pass it reads into memory
-any integer between 0 and 249,999,
-sorts the (at most) 250,000 integers
-and writes them to the output file.
-The second pass sorts the integers from 250,000 to 499,999,
-and so on to the 40th pass,
-which sorts 9,750,000 to 9,999,999.
-A Quicksort would be
-quite efficient for the main-memory sorts,
-and it requires only twenty lines of code
-(as we'll see in Column 11).
-The entire program could therefore be implemented
-in a page or two of code.
-It also has the desirable property that we no longer have to
-worry about using intermediate disk files;
-unfortunately, for that benefit we pay the
-price of reading the entire input file 40 times.
-
-
-A Merge Sort program reads the file once from the input,
-sorts it with the aid of work files
-that are read and written many times,
-and then writes it once.
- Next: Section 1.4. Implementation Sketch.
-
-
-Copyright © 1999
-Lucent Technologies. All rights reserved.
-
-Thu 23 Sep 1999
-
-
-
+
+
+
+
+The obvious program uses a general disk-based Merge Sort
+as a starting point but trims it to exploit the fact that
+we are sorting integers.
+That reduces the two hundred lines of code by a few dozen lines,
+and also makes it run faster.
+It might still take a few days to get the code up and running.
+
+
+A second solution makes even more use of the
+particular nature of this sorting problem.
+If we store each number in seven bytes,
+then we can store about 143,000 numbers
+in the available megabyte.
+If we represent each number as a 32-bit integer, though,
+then we can store 250,000 numbers in the megabyte.
+We will therefore use a program that makes 40
+passes over the input file.
+On the first pass it reads into memory
+any integer between 0 and 249,999,
+sorts the (at most) 250,000 integers
+and writes them to the output file.
+The second pass sorts the integers from 250,000 to 499,999,
+and so on to the 40th pass,
+which sorts 9,750,000 to 9,999,999.
+A Quicksort would be
+quite efficient for the main-memory sorts,
+and it requires only twenty lines of code
+(as we'll see in Column 11).
+The entire program could therefore be implemented
+in a page or two of code.
+It also has the desirable property that we no longer have to
+worry about using intermediate disk files;
+unfortunately, for that benefit we pay the
+price of reading the entire input file 40 times.
+
+
+A Merge Sort program reads the file once from the input,
+sorts it with the aid of work files
+that are read and written many times,
+and then writes it once.
+ Next: Section 1.4. Implementation Sketch.
+
+
+Copyright © 1999
+Lucent Technologies. All rights reserved.
+
+Thu 23 Sep 1999
+
+
+
diff --git a/sec014.html b/sec014.html
index 29664ce..54a5264 100644
--- a/sec014.html
+++ b/sec014.html
@@ -1,104 +1,104 @@
-
-
-
-
-Viewed in this light, the bitmap
-bit vector
-representation of a set screams out to be used.
-We can represent a toy set of nonnegative integers less than 20
-by a string of 20 bits.
-For instance,
-we can store the set {1, 2, 3, 5, 8, 13}
-in this string:
-
-In the real problem,
-the seven decimal digits of each integer
-denote a number less than ten million.
-We'll represent the file by a string of
-ten million bits in which the ith
-bit is on if and only if the integer i is in the file.
-(The programmer found two million spare bits;
-Problem
-5
-investigates what happens when
-a megabyte is a firm limit.)
-This representation uses three attributes of this
-problem not usually found in sorting problems:
-the input is from a relatively small range,
-it contains no duplicates,
-and no data is associated with each record
-beyond the single integer.
-
-
-Given the bitmap
-data structure to represent the set of integers in the file,
-the program can be written in three natural phases.
-The first phase
-initializes the set to empty by turning off all bits.
-The second phase builds the set by reading each integer in the
-file and turning on the appropriate bit.
-The third phase
-produces the sorted output file by inspecting each bit and
-writing out the appropriate integer if the bit is one.
-If n is the number of bits in the vector
-(in this case 10,000,000), the program can be expressed in
-pseudocode as:
-
-This sketch was sufficient for the programmer
-to solve his problem.
-Some of the implementation details he faced
-are described in Problems
-2,
-5
-and
-7.
-
-
-
- Next: Section 1.5. Principles.
-
-
-
-Copyright © 1999
-Lucent Technologies. All rights reserved.
-
-Thu 23 Sep 1999
-
-
-
+
+
+
+
+Viewed in this light, the bitmap
+bit vector
+representation of a set screams out to be used.
+We can represent a toy set of nonnegative integers less than 20
+by a string of 20 bits.
+For instance,
+we can store the set {1, 2, 3, 5, 8, 13}
+in this string:
+
+In the real problem,
+the seven decimal digits of each integer
+denote a number less than ten million.
+We'll represent the file by a string of
+ten million bits in which the ith
+bit is on if and only if the integer i is in the file.
+(The programmer found two million spare bits;
+Problem
+5
+investigates what happens when
+a megabyte is a firm limit.)
+This representation uses three attributes of this
+problem not usually found in sorting problems:
+the input is from a relatively small range,
+it contains no duplicates,
+and no data is associated with each record
+beyond the single integer.
+
+
+Given the bitmap
+data structure to represent the set of integers in the file,
+the program can be written in three natural phases.
+The first phase
+initializes the set to empty by turning off all bits.
+The second phase builds the set by reading each integer in the
+file and turning on the appropriate bit.
+The third phase
+produces the sorted output file by inspecting each bit and
+writing out the appropriate integer if the bit is one.
+If n is the number of bits in the vector
+(in this case 10,000,000), the program can be expressed in
+pseudocode as:
+
+This sketch was sufficient for the programmer
+to solve his problem.
+Some of the implementation details he faced
+are described in Problems
+2,
+5
+and
+7.
+
+
+
+ Next: Section 1.5. Principles.
+
+
+
+Copyright © 1999
+Lucent Technologies. All rights reserved.
+
+Thu 23 Sep 1999
+
+
+
diff --git a/sec015.html b/sec015.html
index f79e4d4..a6fd3f6 100644
--- a/sec015.html
+++ b/sec015.html
@@ -1,147 +1,147 @@
-
-
-
-
-The programmer told me about his problem in a phone call;
-it took us about fifteen minutes to get to the real problem
-and find the bitmap solution.
-It took him a couple of hours to implement the program in a
-few dozen lines of code,
-which was far superior to the hundreds of lines of code
-and the week of programming time that we had feared
-at the start of the phone call.
-And the program was lightning fast:
-while a Merge Sort on disk might have taken many minutes,
-this program took little more than the time to read the
-input and to write the output -- about ten seconds.
-Solution 3 contains timing details on several programs
-for the task.
-
-
-Those facts contain the first lesson from this case study:
-careful analysis of a small problem can sometimes
-yield tremendous practical benefits.
-In this case a few minutes of careful study led to an order of
-magnitude reduction in code length,
-programmer time and run time.
-General Chuck Yeager
-(the first person to fly faster than sound)
-praised an airplane's engine system with the words
-``simple, few parts, easy to maintain, very strong'';
-this program shares those attributes.
-The program's specialized structure, however,
-would be hard to modify if certain dimensions
-of the specifications were changed.
-In addition to the advertising for clever programming,
-this case illustrates the following general principles.
-
-
-The Right Problem.
-Defining the problem was about ninety percent
-of this battle -- I'm glad that the programmer didn't
-settle for the first program I described.
-Problems
-10,
-11
-and
-12
-have elegant solutions once you pose
-the right problem;
-think hard about them before looking at the hints and solutions.
-
-
-The Bitmap Data Structure.
-This data structure represents a dense set
-over a finite domain when each element occurs at
-most once and no other data is associated with the element.
-Even if these conditions aren't satisfied
-(when there are multiple elements or extra data,
-for instance),
-a key from a finite domain can be used as
-an index into a table with more complicated entries;
-see Problems
-6
-and
-8.
-
-
-Multiple-Pass Algorithms.
-These algorithms make several passes over their input
-data, accomplishing a little more each time.
-We saw a 40-pass algorithm in
-Section 1.3;
-Problem 5 encourages you to develop a two-pass algorithm.
-
-
-A Time-Space Tradeoff and One That Isn't.
-Programming folklore and theory abound with
-time-space tradeoffs:
-by using more time, a program can run in less space.
-The two-pass algorithm in Solution 5, for instance,
-doubles a program's run time to halve its space.
-It has been my experience more frequently, though,
-that reducing a program's space requirements also
-reduces its run time.
-(Tradeoffs are common to all engineering disciplines;
-automobile designers, for instance, might trade
-reduced mileage for faster acceleration by adding
-heavy components.
-Mutual improvements are preferred, though.
-A review of a small car I once drove observed that
-``the weight saving on the car's basic structure translates
-into further weight reductions in the various chassis
-components -- and even the elimination of the need
-for some, such as power steering''.)
-The space-efficient structure of bitmaps dramatically
-reduced the run time of sorting.
-There were two reasons that the
-reduction in space led to a reduction in time:
-less data to process means less time to process it,
-and keeping data in main memory rather than on disk
-avoids the overhead of disk accesses.
-Of course,
-the mutual improvement was possible only because the
-original design was far from optimal.
-
-
-A Simple Design.
-Antoine de Saint-Exupery,
-the French writer and aircraft designer, said that,
-``A designer
-knows he has arrived at perfection not when there is no longer
-anything to add, but when there is no longer anything to take
-away.''
-More programmers should judge their work by this criterion.
-Simple programs are usually more
-reliable, secure, robust and efficient than their
-complex cousins,
-and easier to build and to maintain.
-
-
-Stages of Program Design.
-This case illustrates the design process that is described in
-detail in Section 12.4.
-
- Next: Section 1.6. Problems.
-
-
-
-Copyright © 1999
-Lucent Technologies. All rights reserved.
-
-Thu 23 Sep 1999
-
-
-
+
+
+
+
+The programmer told me about his problem in a phone call;
+it took us about fifteen minutes to get to the real problem
+and find the bitmap solution.
+It took him a couple of hours to implement the program in a
+few dozen lines of code,
+which was far superior to the hundreds of lines of code
+and the week of programming time that we had feared
+at the start of the phone call.
+And the program was lightning fast:
+while a Merge Sort on disk might have taken many minutes,
+this program took little more than the time to read the
+input and to write the output -- about ten seconds.
+Solution 3 contains timing details on several programs
+for the task.
+
+
+Those facts contain the first lesson from this case study:
+careful analysis of a small problem can sometimes
+yield tremendous practical benefits.
+In this case a few minutes of careful study led to an order of
+magnitude reduction in code length,
+programmer time and run time.
+General Chuck Yeager
+(the first person to fly faster than sound)
+praised an airplane's engine system with the words
+``simple, few parts, easy to maintain, very strong'';
+this program shares those attributes.
+The program's specialized structure, however,
+would be hard to modify if certain dimensions
+of the specifications were changed.
+In addition to the advertising for clever programming,
+this case illustrates the following general principles.
+
+
+The Right Problem.
+Defining the problem was about ninety percent
+of this battle -- I'm glad that the programmer didn't
+settle for the first program I described.
+Problems
+10,
+11
+and
+12
+have elegant solutions once you pose
+the right problem;
+think hard about them before looking at the hints and solutions.
+
+
+The Bitmap Data Structure.
+This data structure represents a dense set
+over a finite domain when each element occurs at
+most once and no other data is associated with the element.
+Even if these conditions aren't satisfied
+(when there are multiple elements or extra data,
+for instance),
+a key from a finite domain can be used as
+an index into a table with more complicated entries;
+see Problems
+6
+and
+8.
+
+
+Multiple-Pass Algorithms.
+These algorithms make several passes over their input
+data, accomplishing a little more each time.
+We saw a 40-pass algorithm in
+Section 1.3;
+Problem 5 encourages you to develop a two-pass algorithm.
+
+
+A Time-Space Tradeoff and One That Isn't.
+Programming folklore and theory abound with
+time-space tradeoffs:
+by using more time, a program can run in less space.
+The two-pass algorithm in Solution 5, for instance,
+doubles a program's run time to halve its space.
+It has been my experience more frequently, though,
+that reducing a program's space requirements also
+reduces its run time.
+(Tradeoffs are common to all engineering disciplines;
+automobile designers, for instance, might trade
+reduced mileage for faster acceleration by adding
+heavy components.
+Mutual improvements are preferred, though.
+A review of a small car I once drove observed that
+``the weight saving on the car's basic structure translates
+into further weight reductions in the various chassis
+components -- and even the elimination of the need
+for some, such as power steering''.)
+The space-efficient structure of bitmaps dramatically
+reduced the run time of sorting.
+There were two reasons that the
+reduction in space led to a reduction in time:
+less data to process means less time to process it,
+and keeping data in main memory rather than on disk
+avoids the overhead of disk accesses.
+Of course,
+the mutual improvement was possible only because the
+original design was far from optimal.
+
+
+A Simple Design.
+Antoine de Saint-Exupery,
+the French writer and aircraft designer, said that,
+``A designer
+knows he has arrived at perfection not when there is no longer
+anything to add, but when there is no longer anything to take
+away.''
+More programmers should judge their work by this criterion.
+Simple programs are usually more
+reliable, secure, robust and efficient than their
+complex cousins,
+and easier to build and to maintain.
+
+
+Stages of Program Design.
+This case illustrates the design process that is described in
+detail in Section 12.4.
+
+ Next: Section 1.6. Problems.
+
+
+
+Copyright © 1999
+Lucent Technologies. All rights reserved.
+
+Thu 23 Sep 1999
+
+
+
diff --git a/sec016.html b/sec016.html
index c781a1f..a373d50 100644
--- a/sec016.html
+++ b/sec016.html
@@ -1,183 +1,183 @@
-
-
-
-
-The
-Solutions to Column 1
-give answers for some of these problems.
-
-
-
-1.
-If memory were not scarce,
-how would you implement a sort in a language
-with libraries for representing and sorting sets?
-
-
-
-2.
-How would you implement bit vectors
-using bitwise logical operations
-(such as and, or and shift)?
-
-
-
-3.
-Run-time efficiency was an important part of the design goal,
-and the resulting program was efficient enough.
-Implement the bitmap sort on your system
-and measure its run time;
-how does it compare to the system sort
-and to the sorts in Problem 1?
-Assume that n is 10,000,000,
-and that the input file contains 1,000,000 integers.
-
-
-
-4.
-If you take Problem 3 seriously,
-you will face the problem of generating
-k integers less than n without duplicates.
-The simplest approach uses the first c positive integers.
-This extreme data set won't alter the run time of the
-bitmap method by much,
-but it might skew the run time of a system sort.
-How could you generate a file of k unique random
-integers between 0 and n-1 in random order?
-Strive for a short program that is also efficient.
-
-
-
-5.
-The programmer said that he had
-about a megabyte of free storage,
-but the code we sketched uses 1.25 megabytes.
-He was able to scrounge the extra space without much trouble.
-If the megabyte had been a hard and fast boundary,
-what would you have recommended?
-What is the run time of your algorithm?
-
-
-
-6.
-What would you recommend to the programmer if,
-instead of saying that each integer could appear at most once,
-he told you that each integer could appear at most ten times?
-How would your solution change
-as a function of the amount of available storage?
-
-
-
-7.
-[R. Weil]
-The program as sketched has several flaws.
-The first is that
-it assumes that no integer appears twice in the input.
-What happens if one does show up more than once?
-How could the program
-be modified to call an error function in that case?
-What happens when an input integer is less than zero or
-greater than or equal to n?
-What if an input is not numeric?
-What should a program do under those circumstances?
-What other sanity checks could the program incorporate?
-Describe small data sets that test the program,
-including its proper handling of these and other
-ill-behaved cases.
-
-
-
-8.
-When the programmer faced the problem,
-all toll-free phone numbers in the United States
-had the 800 area code.
-Toll-free codes now include 800, 877 and 888,
-and the list is growing.
-How would you sort all of the toll-free numbers using
-only a megabyte?
-How can you store a set of toll-free numbers
-to allow very rapid lookup to determine whether
-a given toll-free number is available or already taken?
-
-
-
-9.
-One problem with trading more space to use less time is that
-initializing the space can itself take a great deal of time.
-Show how to circumvent this problem by designing a technique
-to initialize an entry of a vector to zero the
-first time it is accessed.
-Your scheme should use constant time for initialization and for
-each vector access,
-and use extra space proportional to
-the size of the vector.
-Because this method reduces initialization time by using even
-more space,
-it should be considered only when space is cheap,
-time is dear and the vector is sparse.
-
-
-
-10.
-Before the days of low-cost overnight deliveries,
-a store allowed customers to order items over the telephone,
-which they picked up a few days later.
-The store's database used the customer's telephone number
-as the primary key for retrieval
-(customers know their phone numbers
-and the keys are close to unique).
-How would you organize the store's database to allow orders
-to be inserted and retrieved efficiently?
-
-
-
-11.
-In the early 1980's Lockheed engineers transmitted daily
-a dozen drawings from a Computer Aided Design (CAD)
-system in their Sunnyvale, California,
-plant to a test station in Santa Cruz.
-Although the facilities were just 25 miles apart,
-an automobile courier service took over an hour
-(due to traffic jams and mountain roads)
-and cost a hundred dollars per day.
-Propose alternative data transmission schemes and
-estimate their cost.
-
-
-
-12.
-Pioneers of human space flight soon realized the
-need for writing implements that work well
-in the extreme environment of space.
-A popular urban legend asserts that the United States
-National Aeronautics and Space Administration (NASA)
-solved the problem with a million dollars
-of research to develop a special pen.
-According to the legend,
-how did the Soviets solve the same problem?
-
-
- Next: Section 1.7. Further Reading.
-
-
-
-Copyright © 1999
-Lucent Technologies. All rights reserved.
-
-Th 23 Oct 1999
-
-
-
+
+
+
+
+The
+Solutions to Column 1
+give answers for some of these problems.
+
+
+
+1.
+If memory were not scarce,
+how would you implement a sort in a language
+with libraries for representing and sorting sets?
+
+
+
+2.
+How would you implement bit vectors
+using bitwise logical operations
+(such as and, or and shift)?
+
+
+
+3.
+Run-time efficiency was an important part of the design goal,
+and the resulting program was efficient enough.
+Implement the bitmap sort on your system
+and measure its run time;
+how does it compare to the system sort
+and to the sorts in Problem 1?
+Assume that n is 10,000,000,
+and that the input file contains 1,000,000 integers.
+
+
+
+4.
+If you take Problem 3 seriously,
+you will face the problem of generating
+k integers less than n without duplicates.
+The simplest approach uses the first c positive integers.
+This extreme data set won't alter the run time of the
+bitmap method by much,
+but it might skew the run time of a system sort.
+How could you generate a file of k unique random
+integers between 0 and n-1 in random order?
+Strive for a short program that is also efficient.
+
+
+
+5.
+The programmer said that he had
+about a megabyte of free storage,
+but the code we sketched uses 1.25 megabytes.
+He was able to scrounge the extra space without much trouble.
+If the megabyte had been a hard and fast boundary,
+what would you have recommended?
+What is the run time of your algorithm?
+
+
+
+6.
+What would you recommend to the programmer if,
+instead of saying that each integer could appear at most once,
+he told you that each integer could appear at most ten times?
+How would your solution change
+as a function of the amount of available storage?
+
+
+
+7.
+[R. Weil]
+The program as sketched has several flaws.
+The first is that
+it assumes that no integer appears twice in the input.
+What happens if one does show up more than once?
+How could the program
+be modified to call an error function in that case?
+What happens when an input integer is less than zero or
+greater than or equal to n?
+What if an input is not numeric?
+What should a program do under those circumstances?
+What other sanity checks could the program incorporate?
+Describe small data sets that test the program,
+including its proper handling of these and other
+ill-behaved cases.
+
+
+
+8.
+When the programmer faced the problem,
+all toll-free phone numbers in the United States
+had the 800 area code.
+Toll-free codes now include 800, 877 and 888,
+and the list is growing.
+How would you sort all of the toll-free numbers using
+only a megabyte?
+How can you store a set of toll-free numbers
+to allow very rapid lookup to determine whether
+a given toll-free number is available or already taken?
+
+
+
+9.
+One problem with trading more space to use less time is that
+initializing the space can itself take a great deal of time.
+Show how to circumvent this problem by designing a technique
+to initialize an entry of a vector to zero the
+first time it is accessed.
+Your scheme should use constant time for initialization and for
+each vector access,
+and use extra space proportional to
+the size of the vector.
+Because this method reduces initialization time by using even
+more space,
+it should be considered only when space is cheap,
+time is dear and the vector is sparse.
+
+
+
+10.
+Before the days of low-cost overnight deliveries,
+a store allowed customers to order items over the telephone,
+which they picked up a few days later.
+The store's database used the customer's telephone number
+as the primary key for retrieval
+(customers know their phone numbers
+and the keys are close to unique).
+How would you organize the store's database to allow orders
+to be inserted and retrieved efficiently?
+
+
+
+11.
+In the early 1980's Lockheed engineers transmitted daily
+a dozen drawings from a Computer Aided Design (CAD)
+system in their Sunnyvale, California,
+plant to a test station in Santa Cruz.
+Although the facilities were just 25 miles apart,
+an automobile courier service took over an hour
+(due to traffic jams and mountain roads)
+and cost a hundred dollars per day.
+Propose alternative data transmission schemes and
+estimate their cost.
+
+
+
+12.
+Pioneers of human space flight soon realized the
+need for writing implements that work well
+in the extreme environment of space.
+A popular urban legend asserts that the United States
+National Aeronautics and Space Administration (NASA)
+solved the problem with a million dollars
+of research to develop a special pen.
+According to the legend,
+how did the Soviets solve the same problem?
+
+
+ Next: Section 1.7. Further Reading.
+
+
+
+Copyright © 1999
+Lucent Technologies. All rights reserved.
+
+Th 23 Oct 1999
+
+
+
diff --git a/sec017.html b/sec017.html
index a8aef7f..d06e146 100644
--- a/sec017.html
+++ b/sec017.html
@@ -1,63 +1,63 @@
-
-
-
-
-This little exercise has only skimmed the fascinating topic
-of specifying a program.
-For a deep insight into this crucial activity,
-see Michael Jackson's
-Software Requirements & Specifications,
-published by Addison-Wesley in 1995.
-The tough topics in the book are presented as
-a delightful collection of independent
-but reinforcing little essays.
-
-
-In the case study described in this column,
-the programmer's main problem
-was not so much technical as psychological:
-he couldn't make progress because he was trying to solve
-the wrong problem.
-We finally solved his problem by breaking through
-his conceptual block and solving an easier problem.
-Conceptual Blockbusting
-by James L. Adams
-(the third edition was published by Perseus in 1986)
-studies this kind of leap and is generally a pleasant prod
-towards more creative thinking.
-Although it was not written with programmers in mind,
-many of its lessons are particularly appropriate for
-programming problems.
-Adams defines conceptual blocks as ``mental walls that block
-the problem-solver from correctly perceiving a problem
-or conceiving its solution'';
-Problems
-10,
-11
-and
-12
-encourage you to bust some.
-
-
-
-
-Copyright © 1999
-Lucent Technologies. All rights reserved.
-
-Thu 23 Sep 1999
-
-
-
+
+
+
+
+This little exercise has only skimmed the fascinating topic
+of specifying a program.
+For a deep insight into this crucial activity,
+see Michael Jackson's
+Software Requirements & Specifications,
+published by Addison-Wesley in 1995.
+The tough topics in the book are presented as
+a delightful collection of independent
+but reinforcing little essays.
+
+
+In the case study described in this column,
+the programmer's main problem
+was not so much technical as psychological:
+he couldn't make progress because he was trying to solve
+the wrong problem.
+We finally solved his problem by breaking through
+his conceptual block and solving an easier problem.
+Conceptual Blockbusting
+by James L. Adams
+(the third edition was published by Perseus in 1986)
+studies this kind of leap and is generally a pleasant prod
+towards more creative thinking.
+Although it was not written with programmers in mind,
+many of its lessons are particularly appropriate for
+programming problems.
+Adams defines conceptual blocks as ``mental walls that block
+the problem-solver from correctly perceiving a problem
+or conceiving its solution'';
+Problems
+10,
+11
+and
+12
+encourage you to bust some.
+
+
+
+
+Copyright © 1999
+Lucent Technologies. All rights reserved.
+
+Thu 23 Sep 1999
+
+
+
diff --git a/sec0510.html b/sec0510.html
index cd7ea77..a8a2e39 100644
--- a/sec0510.html
+++ b/sec0510.html
@@ -1,137 +1,137 @@
-
-
-
-
-Every programmer knows that debugging is hard.
-Great debuggers, though,
-can make the job look simple.
-Distraught programmers describe a bug that
-they've been chasing for hours,
-the master asks a few questions,
-and minutes later the programmers
-are staring at the faulty code.
-The expert debugger never forgets that
-there has to be a logical explanation,
-no matter how mysterious the system's behavior
-may seem when first observed.
-
-
-That attitude is illustrated in an anecdote from
-IBM's Yorktown Heights Research Center.
-A programmer had recently installed a new workstation.
-All was fine when he was sitting down,
-but he couldn't log in to the system when he was standing up.
-That behavior was one hundred percent repeatable:
-he could always log in when sitting and never when standing.
-
-
-Most of us just sit back and marvel at such a story.
-How could that workstation know whether
-the poor guy was sitting or standing?
-Good debuggers, though, know that there has to be a reason.
-Electrical theories are the easiest to hypothesize.
-Was there a loose wire under the carpet,
-or problems with static electricity?
-But electrical problems are rarely
-one-hundred-percent consistent.
-An alert colleague finally asked the right question:
-how did the programmer log in when he was sitting
-and when he was standing?
-Hold your hands out and try it yourself.
-
-
-The problem was in the keyboard:
-the tops of two keys were switched.
-When the programmer was seated he was a
-touch typist and the problem went unnoticed,
-but when he stood he was led astray by hunting and pecking.
-With this hint and a convenient screwdriver,
-the expert debugger swapped the two wandering keytops
-and all was well.
-
-
-A banking system built in Chicago
-had worked correctly for many months,
-but unexpectedly quit the first time
-it was used on international data.
-Programmers spent days scouring the code,
-but they couldn't find any stray command
-that would quit the program.
-When they observed the behavior more closely,
-they found that the program quit
-as they entered data for the country of Ecuador.
-Closer inspection showed that when
-the user typed the name of the capital city (Quito),
-the program interpreted that as a request to quit the run!
-
-
-Bob Martin once watched a system ``work once twice''.
-It handled the first transaction correctly,
-then exhibited a minor flaw in all later transactions.
-When the system was rebooted,
-it once again correctly processed the first transaction,
-and failed on all subsequent transactions.
-When Martin characterized the behavior as
-having ``worked once twice'',
-the developers immediately knew to look for
-a variable that was initialized correctly
-when the program was loaded,
-but was not reset properly after the first transaction.
-
-
-In all cases the right questions guided wise programmers
-to nasty bugs in short order:
-``What do you do differently sitting and standing?
-May I watch you logging in each way?''
-``Precisely what did you type before the program quit?''
-``Did the program ever work correctly before
-it started failing?
-How many times?''
-
-
-Rick Lemons
-said that the best lesson he ever had
-in debugging was watching a magic show.
-The magician did a half-dozen impossible tricks,
-and Lemons found himself tempted to believe them.
-He then reminded himself that the impossible isn't possible,
-and probed each stunt to resolve its apparent inconsistency.
-He started with what he knew to be bedrock truth -- the
-laws of physics -- and worked from there
-to find a simple explanation for each trick.
-This attitude makes Lemons one of the best debuggers
-I've ever seen.
-
-
-The best book I've seen on debugging is
-The Medical Detectives
-by Berton Roueche',
-published by Penguin in 1991.
-The heroes in the book debug complex systems,
-ranging from mildly sick people to very sick towns.
-The problem-solving methods they use are directly applicable
-to debugging computer systems.
-These true stories are as spellbinding as any fiction.
-
-
-
-
-Copyright © 2000
-Lucent Technologies. All rights reserved.
-
-Mon 28 Feb 2000
-
-
-
+
+
+
+
+Every programmer knows that debugging is hard.
+Great debuggers, though,
+can make the job look simple.
+Distraught programmers describe a bug that
+they've been chasing for hours,
+the master asks a few questions,
+and minutes later the programmers
+are staring at the faulty code.
+The expert debugger never forgets that
+there has to be a logical explanation,
+no matter how mysterious the system's behavior
+may seem when first observed.
+
+
+That attitude is illustrated in an anecdote from
+IBM's Yorktown Heights Research Center.
+A programmer had recently installed a new workstation.
+All was fine when he was sitting down,
+but he couldn't log in to the system when he was standing up.
+That behavior was one hundred percent repeatable:
+he could always log in when sitting and never when standing.
+
+
+Most of us just sit back and marvel at such a story.
+How could that workstation know whether
+the poor guy was sitting or standing?
+Good debuggers, though, know that there has to be a reason.
+Electrical theories are the easiest to hypothesize.
+Was there a loose wire under the carpet,
+or problems with static electricity?
+But electrical problems are rarely
+one-hundred-percent consistent.
+An alert colleague finally asked the right question:
+how did the programmer log in when he was sitting
+and when he was standing?
+Hold your hands out and try it yourself.
+
+
+The problem was in the keyboard:
+the tops of two keys were switched.
+When the programmer was seated he was a
+touch typist and the problem went unnoticed,
+but when he stood he was led astray by hunting and pecking.
+With this hint and a convenient screwdriver,
+the expert debugger swapped the two wandering keytops
+and all was well.
+
+
+A banking system built in Chicago
+had worked correctly for many months,
+but unexpectedly quit the first time
+it was used on international data.
+Programmers spent days scouring the code,
+but they couldn't find any stray command
+that would quit the program.
+When they observed the behavior more closely,
+they found that the program quit
+as they entered data for the country of Ecuador.
+Closer inspection showed that when
+the user typed the name of the capital city (Quito),
+the program interpreted that as a request to quit the run!
+
+
+Bob Martin once watched a system ``work once twice''.
+It handled the first transaction correctly,
+then exhibited a minor flaw in all later transactions.
+When the system was rebooted,
+it once again correctly processed the first transaction,
+and failed on all subsequent transactions.
+When Martin characterized the behavior as
+having ``worked once twice'',
+the developers immediately knew to look for
+a variable that was initialized correctly
+when the program was loaded,
+but was not reset properly after the first transaction.
+
+
+In all cases the right questions guided wise programmers
+to nasty bugs in short order:
+``What do you do differently sitting and standing?
+May I watch you logging in each way?''
+``Precisely what did you type before the program quit?''
+``Did the program ever work correctly before
+it started failing?
+How many times?''
+
+
+Rick Lemons
+said that the best lesson he ever had
+in debugging was watching a magic show.
+The magician did a half-dozen impossible tricks,
+and Lemons found himself tempted to believe them.
+He then reminded himself that the impossible isn't possible,
+and probed each stunt to resolve its apparent inconsistency.
+He started with what he knew to be bedrock truth -- the
+laws of physics -- and worked from there
+to find a simple explanation for each trick.
+This attitude makes Lemons one of the best debuggers
+I've ever seen.
+
+
+The best book I've seen on debugging is
+The Medical Detectives
+by Berton Roueche',
+published by Penguin in 1991.
+The heroes in the book debug complex systems,
+ranging from mildly sick people to very sick towns.
+The problem-solving methods they use are directly applicable
+to debugging computer systems.
+These true stories are as spellbinding as any fiction.
+
+
+
+
+Copyright © 2000
+Lucent Technologies. All rights reserved.
+
+Mon 28 Feb 2000
+
+
+
diff --git a/sec071.html b/sec071.html
index 35307ee..676037b 100644
--- a/sec071.html
+++ b/sec071.html
@@ -1,256 +1,256 @@
-
-
-
-
-These reminders can be helpful in making
-back-of-the-envelope calculations.
-
-
-Two Answers Are Better Than One.
-When I asked Peter Weinberger how much water flows out of
-the Mississippi per day,
-he responded, ``As much as flows in.''
-He then estimated that the Mississippi basin
-was about 1000 by 1000 miles,
-and that the annual runoff from rainfall
-there was about one foot
-(or one five-thousandth of a mile).
-That gives
-
-
-As a cheating triple check,
-an almanac reported that the river's
-discharge is 640,000 cubic feet per second.
-Working from that gives
-
-
-
-Quick Checks.
-Polya devotes three pages of his
-How to Solve It
-to ``Test by Dimension'', which he describes as a
-``well-known, quick and efficient means to check
-geometrical or physical formulas''.
-The first rule is that the dimensions in a sum must be the same,
-which is in turn the dimension of the sum -- you
-can add feet together to get feet,
-but you can't add seconds to pounds.
-The second rule is that the dimension of a product is the
-product of the dimensions.
-The examples above obey both rules;
-multiplying
-
-
-A simple table can help you keep track of dimensions
-in complicated expressions like those above.
-To perform Weinberger's calculation,
-we first write down the three original factors.
-
-Dimension tests check the form of equations.
-Check your multiplications and divisions with an old
-trick from slide rule days:
-independently compute the leading digit and the exponent.
-One can make several quick checks for addition.
-
-
-Above all, don't forget common sense:
-be suspicious of any calculations that show
-that the Mississippi River discharges 100
-gallons of water per day.
-
-
-Rules of Thumb.
-I first learned the ``Rule of 72'' in a course
-on accounting.
-Assume that you invest a sum of money for
-y years at an interest rate of r percent per year.
-The financial version of the rule says that if
-r times y = 72,
-then your money will roughly double.
-The approximation is quite accurate:
-investing $1000 at 6 percent interest
-for 12 years gives $2,012,
-and $1000 at 8 percent for 9 years gives $1,999.
-
-
-The Rule of 72 is handy for estimating the growth of any
-exponential process.
-If a bacterial colony in a dish grows
-at the rate of three percent per hour,
-then it doubles in size every day.
-And doubling brings programmers back to
-familiar rules of thumb:
-because 210=1024,
-ten doublings is about a thousand,
-twenty doublings is about a million,
-and thirty doublings is about a billion.
-
-
-Suppose that an exponential program
-takes ten seconds to solve a problem of size n=40,
-and that increasing n by one
-increases the run time by 12 percent
-(we probably learned this by
-plotting its growth on a logarithmic scale).
-The Rule of 72 tells us that the run time doubles
-when n increases by 6,
-or goes up by a factor of about 1000 when n increases by 60.
-When n=100,
-the program should therefore take about 10,000 seconds,
-or a few hours.
-But what happens when n increases to 160,
-and the time rises to 107 seconds?
-How much time is that?
-
-
-You might find it hard to memorize that there are
-3.155x107 seconds in a year.
-On the other hand, it is hard to forget
-Tom Duff's handy rule of thumb that,
-to within half a percent,
-
-Practice.
-As with many activities,
-your estimation skills can only be improved with practice.
-Try the problems at the end of this column,
-and the estimation quiz in
-Appendix 2
-(a similar quiz once gave me a much-needed dose of
-humility about my estimation prowess).
-Section 7.8
-describes quick calculations in everyday life.
-Most workplaces provide ample opportunities for
-back-of-the-envelope estimates.
-How many foam ``packing peanuts'' came in that box?
-How much time do people at your facility spend
-waiting in line every day,
-for morning coffee, lunch, photocopiers and the like?
-How much does that cost the company in (loaded) salary?
-And the next time you're
-really
-bored at the lunch table,
-ask your colleagues how much water flows out of the
-Mississippi River each day.
-
-
- Next: Section 7.2. Performance Estimates.
-
-
-Copyright © 1999
-Lucent Technologies. All rights reserved.
-
-Sun 15 Aug 1999
-
-
-
+
+
+
+
+These reminders can be helpful in making
+back-of-the-envelope calculations.
+
+
+Two Answers Are Better Than One.
+When I asked Peter Weinberger how much water flows out of
+the Mississippi per day,
+he responded, ``As much as flows in.''
+He then estimated that the Mississippi basin
+was about 1000 by 1000 miles,
+and that the annual runoff from rainfall
+there was about one foot
+(or one five-thousandth of a mile).
+That gives
+
+
+As a cheating triple check,
+an almanac reported that the river's
+discharge is 640,000 cubic feet per second.
+Working from that gives
+
+
+
+Quick Checks.
+Polya devotes three pages of his
+How to Solve It
+to ``Test by Dimension'', which he describes as a
+``well-known, quick and efficient means to check
+geometrical or physical formulas''.
+The first rule is that the dimensions in a sum must be the same,
+which is in turn the dimension of the sum -- you
+can add feet together to get feet,
+but you can't add seconds to pounds.
+The second rule is that the dimension of a product is the
+product of the dimensions.
+The examples above obey both rules;
+multiplying
+
+
+A simple table can help you keep track of dimensions
+in complicated expressions like those above.
+To perform Weinberger's calculation,
+we first write down the three original factors.
+
+Dimension tests check the form of equations.
+Check your multiplications and divisions with an old
+trick from slide rule days:
+independently compute the leading digit and the exponent.
+One can make several quick checks for addition.
+
+
+Above all, don't forget common sense:
+be suspicious of any calculations that show
+that the Mississippi River discharges 100
+gallons of water per day.
+
+
+Rules of Thumb.
+I first learned the ``Rule of 72'' in a course
+on accounting.
+Assume that you invest a sum of money for
+y years at an interest rate of r percent per year.
+The financial version of the rule says that if
+r times y = 72,
+then your money will roughly double.
+The approximation is quite accurate:
+investing $1000 at 6 percent interest
+for 12 years gives $2,012,
+and $1000 at 8 percent for 9 years gives $1,999.
+
+
+The Rule of 72 is handy for estimating the growth of any
+exponential process.
+If a bacterial colony in a dish grows
+at the rate of three percent per hour,
+then it doubles in size every day.
+And doubling brings programmers back to
+familiar rules of thumb:
+because 210=1024,
+ten doublings is about a thousand,
+twenty doublings is about a million,
+and thirty doublings is about a billion.
+
+
+Suppose that an exponential program
+takes ten seconds to solve a problem of size n=40,
+and that increasing n by one
+increases the run time by 12 percent
+(we probably learned this by
+plotting its growth on a logarithmic scale).
+The Rule of 72 tells us that the run time doubles
+when n increases by 6,
+or goes up by a factor of about 1000 when n increases by 60.
+When n=100,
+the program should therefore take about 10,000 seconds,
+or a few hours.
+But what happens when n increases to 160,
+and the time rises to 107 seconds?
+How much time is that?
+
+
+You might find it hard to memorize that there are
+3.155x107 seconds in a year.
+On the other hand, it is hard to forget
+Tom Duff's handy rule of thumb that,
+to within half a percent,
+
+Practice.
+As with many activities,
+your estimation skills can only be improved with practice.
+Try the problems at the end of this column,
+and the estimation quiz in
+Appendix 2
+(a similar quiz once gave me a much-needed dose of
+humility about my estimation prowess).
+Section 7.8
+describes quick calculations in everyday life.
+Most workplaces provide ample opportunities for
+back-of-the-envelope estimates.
+How many foam ``packing peanuts'' came in that box?
+How much time do people at your facility spend
+waiting in line every day,
+for morning coffee, lunch, photocopiers and the like?
+How much does that cost the company in (loaded) salary?
+And the next time you're
+really
+bored at the lunch table,
+ask your colleagues how much water flows out of the
+Mississippi River each day.
+
+
+ Next: Section 7.2. Performance Estimates.
+
+
+Copyright © 1999
+Lucent Technologies. All rights reserved.
+
+Sun 15 Aug 1999
+
+
+
diff --git a/sec072.html b/sec072.html
index f20c09d..6ec1bab 100644
--- a/sec072.html
+++ b/sec072.html
@@ -1,183 +1,183 @@
-
-
-
-
-Let's turn now to a quick calculation in computing.
-Nodes in your data structure
-(it might be a linked list or a hash table)
-hold an integer and a pointer to a node:
-
-Looking at my system performance monitor shows that
-my 128-megabyte machine typically has about 85 megabytes free.
-(I've verified that by running the vector rotation code
-from Column 2 to see when the disk starts thrashing.)
-But how much memory will a node take?
-In the old days of 16-bit machines,
-a pointer and an integer would take four bytes.
-As I write this edition of the book,
-32-bit integers and pointers are most common,
-so I would expect the answer to be eight bytes.
-But every now and then I compile in 64-bit mode,
-so it might take sixteen bytes.
-We can find out the answer for any particular system
-with a single line of C:
-
-So when I used two million of those eight-byte records,
-why did my 128-megabyte machine start thrashing like crazy?
-They key is that I allocated them dynamically,
-using the C malloc function
-(similar to the C++ new operator).
-I had assumed that the eight-byte records might have another
-8 bytes of overhead;
-I expected the nodes to take a total of about 32 megabytes.
-In fact, each node had 40 bytes of overhead
-to consume a total of 48 bytes per record.
-The two million records therefore used a total of 96 megabytes.
-(On other systems and compilers, though,
-the records had just 8 bytes of overhead each.)
-
-
-Appendix 3
-describes a program that explores
-the memory cost of several common structures.
-The first lines it produces are made with the
-sizeof operator:
-
-Let's try one more quick computing quiz.
-You know that the run time of your numerical algorithm
-is dominated by its n3 square root operations,
-and n=1000 in this application.
-About how long will your program take to compute
-the one billion square roots?
-
-
-To find the answer on my system,
-I'd start with this little C program:
-
-But will a square root in a real program take 200 nanoseconds?
-It might be much slower:
-perhaps the square root function cached the most
-recent argument as a starting value.
-Calling such a function repeatedly with the same argument might
-give it an unrealistic advantage.
-Then again, in practice the function might be much faster:
-I compiled the program with optimization disabled
-(optimization removed the main loop,
-so it always ran in zero time).
-Appendix 3
-describes how to expand this tiny
-program to produce a one-page description
-of the time costs of primitive C operations for a given system.
-
-
-How fast is networking?
-To find out,
-I typed ping machine-name.
-It takes a few milliseconds to ping a machine in
-the same building,
-so that represents the startup time.
-On a good day,
-I can ping a machine on the other coast of the
-United States in about 70 milliseconds
-(traversing the 5000 miles of the round-trip voyage
-at the speed of light
-accounts for about 27 of those milliseconds);
-on a bad day,
-I get timed out after waiting 1000 milliseconds.
-Measuring the time to copy a large file shows
-that a ten-megabit Ethernet moves about a
-megabyte a second
-(that is, it achieves about 80 percent of its
-potential bandwidth).
-Similarly, a hundred-megabit Ethernet with the
-wind at its back moves ten megabytes a second.
-
-
-Little experiments can put key parameters
-at your fingertips.
-Database designers should know the times for
-reading and writing records,
-and for joins of various forms.
-Graphics programmers should know the cost
-of key screen operations.
-The short time required to do such little experiments
-today will be more than paid in the time you
-save by making wise decisions tomorrow.
-
-
- Next: Section 7.3. Safety Factors.
-
-
-Copyright © 1999
-Lucent Technologies. All rights reserved.
-
-Mon 9 Aug 1999
-
-
-
+
+
+
+
+Let's turn now to a quick calculation in computing.
+Nodes in your data structure
+(it might be a linked list or a hash table)
+hold an integer and a pointer to a node:
+
+Looking at my system performance monitor shows that
+my 128-megabyte machine typically has about 85 megabytes free.
+(I've verified that by running the vector rotation code
+from Column 2 to see when the disk starts thrashing.)
+But how much memory will a node take?
+In the old days of 16-bit machines,
+a pointer and an integer would take four bytes.
+As I write this edition of the book,
+32-bit integers and pointers are most common,
+so I would expect the answer to be eight bytes.
+But every now and then I compile in 64-bit mode,
+so it might take sixteen bytes.
+We can find out the answer for any particular system
+with a single line of C:
+
+So when I used two million of those eight-byte records,
+why did my 128-megabyte machine start thrashing like crazy?
+They key is that I allocated them dynamically,
+using the C malloc function
+(similar to the C++ new operator).
+I had assumed that the eight-byte records might have another
+8 bytes of overhead;
+I expected the nodes to take a total of about 32 megabytes.
+In fact, each node had 40 bytes of overhead
+to consume a total of 48 bytes per record.
+The two million records therefore used a total of 96 megabytes.
+(On other systems and compilers, though,
+the records had just 8 bytes of overhead each.)
+
+
+Appendix 3
+describes a program that explores
+the memory cost of several common structures.
+The first lines it produces are made with the
+sizeof operator:
+
+Let's try one more quick computing quiz.
+You know that the run time of your numerical algorithm
+is dominated by its n3 square root operations,
+and n=1000 in this application.
+About how long will your program take to compute
+the one billion square roots?
+
+
+To find the answer on my system,
+I'd start with this little C program:
+
+But will a square root in a real program take 200 nanoseconds?
+It might be much slower:
+perhaps the square root function cached the most
+recent argument as a starting value.
+Calling such a function repeatedly with the same argument might
+give it an unrealistic advantage.
+Then again, in practice the function might be much faster:
+I compiled the program with optimization disabled
+(optimization removed the main loop,
+so it always ran in zero time).
+Appendix 3
+describes how to expand this tiny
+program to produce a one-page description
+of the time costs of primitive C operations for a given system.
+
+
+How fast is networking?
+To find out,
+I typed ping machine-name.
+It takes a few milliseconds to ping a machine in
+the same building,
+so that represents the startup time.
+On a good day,
+I can ping a machine on the other coast of the
+United States in about 70 milliseconds
+(traversing the 5000 miles of the round-trip voyage
+at the speed of light
+accounts for about 27 of those milliseconds);
+on a bad day,
+I get timed out after waiting 1000 milliseconds.
+Measuring the time to copy a large file shows
+that a ten-megabit Ethernet moves about a
+megabyte a second
+(that is, it achieves about 80 percent of its
+potential bandwidth).
+Similarly, a hundred-megabit Ethernet with the
+wind at its back moves ten megabytes a second.
+
+
+Little experiments can put key parameters
+at your fingertips.
+Database designers should know the times for
+reading and writing records,
+and for joins of various forms.
+Graphics programmers should know the cost
+of key screen operations.
+The short time required to do such little experiments
+today will be more than paid in the time you
+save by making wise decisions tomorrow.
+
+
+ Next: Section 7.3. Safety Factors.
+
+
+Copyright © 1999
+Lucent Technologies. All rights reserved.
+
+Mon 9 Aug 1999
+
+
+
diff --git a/sec073.html b/sec073.html
index 6f7eac1..e818f17 100644
--- a/sec073.html
+++ b/sec073.html
@@ -1,123 +1,123 @@
-
-
-
-
-The output of any calculation is only as good as its input.
-With good data, simple calculations can yield
-accurate answers that are sometimes quite useful.
-Don Knuth once wrote a disk sorting package,
-only to find that it took twice
-the time predicted by his calculations.
-Diligent checking uncovered the flaw:
-due to a software bug, the
-system's one-year-old disks had run at only
-half their advertised speed for their entire lives.
-When the bug was fixed,
-Knuth's sorting package behaved as predicted
-and every other disk-bound program also ran faster.
-
-
-Often, though,
-sloppy input is enough to get into the right ballpark.
-(The estimation quiz in Appendix 2 may help you to
-judge the quality of your guesses.)
-If you guess about twenty percent here and fifty percent there
-and still find that a design is a hundred
-times above or below specification,
-additional accuracy isn't needed.
-But before placing too much confidence
-in a twenty percent margin of error,
-consider Vic Vyssotsky's advice from
-a talk he has given on several occasions.
-
-
-``Most of you'', says Vyssotsky,
-``probably recall pictures of `Galloping Gertie', the Tacoma
-Narrows Bridge which tore itself apart in a windstorm in 1940.
-Well, suspension bridges had been ripping themselves
-apart that way for eighty years or so before Galloping Gertie.
-It's an aerodynamic lift phenomenon,
-and to do a proper engineering calculation of the forces,
-which involve drastic nonlinearities,
-you have to use the mathematics and concepts of
-Kolmogorov to model the eddy spectrum.
-Nobody really knew how to do this correctly in detail until
-the 1950's or thereabouts.
-So, why hasn't the Brooklyn Bridge torn itself apart,
-like Galloping Gertie?
-
-
-``It's because John Roebling had sense enough to know what he
-didn't know.
-His notes and letters on the design of the
-Brooklyn Bridge still exist,
-and they are a fascinating example of a good engineer
-recognizing the limits of his knowledge.
-He knew about aerodynamic lift on suspension bridges;
-he had watched it.
-And he knew he didn't know enough to model it.
-So he designed the stiffness of the truss on the Brooklyn Bridge
-roadway to be
- six times
-what a normal calculation based on known static and dynamic
-loads would have called for.
-And, he specified a network of
-diagonal stays running down to the roadway,
-to stiffen the entire bridge structure.
-Go look at those sometime; they're almost unique.
-
-
-``When Roebling was asked whether his proposed bridge wouldn't
-collapse like so many others, he said, `No, because I designed it
-six times as strong as it needs to be, to prevent that from happening.'
-
-
-``Roebling was a good engineer,
-and he built a good bridge,
-by employing a huge safety factor to compensate for his ignorance.
-Do we do that?
-I submit to you that in calculating performance of our real-time
-software systems we ought to derate them by a factor of two,
-or four, or six,
-to compensate for our ignorance.
-In making reliability/availability commitments,
-we ought to stay back from the objectives we think
-we can meet by a factor of ten,
-to compensate for our ignorance.
-In estimating size and cost and schedule,
-we should be conservative by a factor of two
-or four to compensate for our ignorance.
-We should design the way John Roebling did,
-and not the way his contemporaries did -- so far as I know,
-none of the suspension bridges built by Roebling's contemporaries
-in the United States still stands,
-and a quarter of all the bridges of any type
-built in the U.S. in the 1870's collapsed within ten years of
-their construction.
-
-
-``Are we engineers, like John Roebling? I wonder.''
-
-
- Next: Section 7.4. Little's Law.
-
-
-Copyright © 1999
-Lucent Technologies. All rights reserved.
-
-Mon 9 Aug 1999
-
-
-
+
+
+
+
+The output of any calculation is only as good as its input.
+With good data, simple calculations can yield
+accurate answers that are sometimes quite useful.
+Don Knuth once wrote a disk sorting package,
+only to find that it took twice
+the time predicted by his calculations.
+Diligent checking uncovered the flaw:
+due to a software bug, the
+system's one-year-old disks had run at only
+half their advertised speed for their entire lives.
+When the bug was fixed,
+Knuth's sorting package behaved as predicted
+and every other disk-bound program also ran faster.
+
+
+Often, though,
+sloppy input is enough to get into the right ballpark.
+(The estimation quiz in Appendix 2 may help you to
+judge the quality of your guesses.)
+If you guess about twenty percent here and fifty percent there
+and still find that a design is a hundred
+times above or below specification,
+additional accuracy isn't needed.
+But before placing too much confidence
+in a twenty percent margin of error,
+consider Vic Vyssotsky's advice from
+a talk he has given on several occasions.
+
+
+``Most of you'', says Vyssotsky,
+``probably recall pictures of `Galloping Gertie', the Tacoma
+Narrows Bridge which tore itself apart in a windstorm in 1940.
+Well, suspension bridges had been ripping themselves
+apart that way for eighty years or so before Galloping Gertie.
+It's an aerodynamic lift phenomenon,
+and to do a proper engineering calculation of the forces,
+which involve drastic nonlinearities,
+you have to use the mathematics and concepts of
+Kolmogorov to model the eddy spectrum.
+Nobody really knew how to do this correctly in detail until
+the 1950's or thereabouts.
+So, why hasn't the Brooklyn Bridge torn itself apart,
+like Galloping Gertie?
+
+
+``It's because John Roebling had sense enough to know what he
+didn't know.
+His notes and letters on the design of the
+Brooklyn Bridge still exist,
+and they are a fascinating example of a good engineer
+recognizing the limits of his knowledge.
+He knew about aerodynamic lift on suspension bridges;
+he had watched it.
+And he knew he didn't know enough to model it.
+So he designed the stiffness of the truss on the Brooklyn Bridge
+roadway to be
+ six times
+what a normal calculation based on known static and dynamic
+loads would have called for.
+And, he specified a network of
+diagonal stays running down to the roadway,
+to stiffen the entire bridge structure.
+Go look at those sometime; they're almost unique.
+
+
+``When Roebling was asked whether his proposed bridge wouldn't
+collapse like so many others, he said, `No, because I designed it
+six times as strong as it needs to be, to prevent that from happening.'
+
+
+``Roebling was a good engineer,
+and he built a good bridge,
+by employing a huge safety factor to compensate for his ignorance.
+Do we do that?
+I submit to you that in calculating performance of our real-time
+software systems we ought to derate them by a factor of two,
+or four, or six,
+to compensate for our ignorance.
+In making reliability/availability commitments,
+we ought to stay back from the objectives we think
+we can meet by a factor of ten,
+to compensate for our ignorance.
+In estimating size and cost and schedule,
+we should be conservative by a factor of two
+or four to compensate for our ignorance.
+We should design the way John Roebling did,
+and not the way his contemporaries did -- so far as I know,
+none of the suspension bridges built by Roebling's contemporaries
+in the United States still stands,
+and a quarter of all the bridges of any type
+built in the U.S. in the 1870's collapsed within ten years of
+their construction.
+
+
+``Are we engineers, like John Roebling? I wonder.''
+
+
+ Next: Section 7.4. Little's Law.
+
+
+Copyright © 1999
+Lucent Technologies. All rights reserved.
+
+Mon 9 Aug 1999
+
+
+
diff --git a/sec074.html b/sec074.html
index 11b3493..f84ffe6 100644
--- a/sec074.html
+++ b/sec074.html
@@ -1,102 +1,102 @@
-
-
-
-
-Most back-of-the-envelope calculations use
-obvious rules:
-total cost is unit cost times number of units.
-Sometimes, though, one needs a more subtle insight.
-Bruce Weide
-wrote the following note about a surprisingly versatile rule.
-
-
-``The `operational analysis' introduced by Denning and Buzen (see
-Computing Surveys 10,
-3, November 1978, 225-261) is much more general than
-queueing network models of computer systems.
-Their exposition is excellent, but
-because of the article's limited focus,
-they didn't explore the generality of Little's Law.
-The proof methods have nothing to do with queues
-or with computer systems.
-Imagine any system in which things enter and leave.
-Little's Law states that
-`The average number of things in the system
-is the product of the average rate at which things leave
-the system and the average time each one spends in the system.'
-(And if there is a gross `flow balance' of things entering and
-leaving, the exit rate is also the entry rate.)
-
-
-``I teach this technique of performance analysis in my
-computer architecture classes at Ohio State University.
-But I try to emphasize that the result is a general law of systems
-theory, and can be applied to many other kinds of systems.
-For instance, if you're in line waiting to get into a popular
-nightspot, you might figure out how long you'll have to
-wait by standing there for a while and trying to estimate
-the rate at which people are entering.
-With Little's Law, though, you could reason,
-`This place holds about 60 people,
-and the average Joe will be in there about 3 hours,
-so we're entering at the rate of about 20 people an hour.
-The line has 20 people in it,
-so that means we'll wait about an hour.
-Let's go home and read
-Programming Pearls
-instead.'
-You get the picture.''
-
-
-Peter Denning
-succinctly phrases this rule as
-``The average number of objects in a queue is the product of the
-entry rate and the average holding time.''
-He applies it to his wine cellar:
-``I have 150 cases of wine in my basement and I consume
-(and purchase) 25 cases per year.
-How long do I hold each case?
-Little's Law tells me to divide 150 cases
-by 25 cases/year, which gives 6 years per case.''
-
-
-He then turns to more serious applications.
-``The response-time formula for a multi-user system can be proved
-using Little's Law and flow balance.
-Assume n users of average think time z are connected
-to an arbitrary system with response time r.
-Each user cycles between thinking and waiting-for-response,
-so the total number of jobs in the meta-system
-(consisting of users and the computer system)
-is fixed at n.
-If you cut the path from the system's output to the users,
-you see a meta-system with average load n,
-average response time z+r,
-and throughput x (measured in jobs per time unit).
-Little's Law says n = x*(z+r),
-and solving for r gives r = n/x - z.''
-
-
- Next: Section 7.5. Principles.
-
-
-
-Copyright © 1999
-Lucent Technologies. All rights reserved.
-
-Mon 9 Aug 1999
-
-
-
+
+
+
+
+Most back-of-the-envelope calculations use
+obvious rules:
+total cost is unit cost times number of units.
+Sometimes, though, one needs a more subtle insight.
+Bruce Weide
+wrote the following note about a surprisingly versatile rule.
+
+
+``The `operational analysis' introduced by Denning and Buzen (see
+Computing Surveys 10,
+3, November 1978, 225-261) is much more general than
+queueing network models of computer systems.
+Their exposition is excellent, but
+because of the article's limited focus,
+they didn't explore the generality of Little's Law.
+The proof methods have nothing to do with queues
+or with computer systems.
+Imagine any system in which things enter and leave.
+Little's Law states that
+`The average number of things in the system
+is the product of the average rate at which things leave
+the system and the average time each one spends in the system.'
+(And if there is a gross `flow balance' of things entering and
+leaving, the exit rate is also the entry rate.)
+
+
+``I teach this technique of performance analysis in my
+computer architecture classes at Ohio State University.
+But I try to emphasize that the result is a general law of systems
+theory, and can be applied to many other kinds of systems.
+For instance, if you're in line waiting to get into a popular
+nightspot, you might figure out how long you'll have to
+wait by standing there for a while and trying to estimate
+the rate at which people are entering.
+With Little's Law, though, you could reason,
+`This place holds about 60 people,
+and the average Joe will be in there about 3 hours,
+so we're entering at the rate of about 20 people an hour.
+The line has 20 people in it,
+so that means we'll wait about an hour.
+Let's go home and read
+Programming Pearls
+instead.'
+You get the picture.''
+
+
+Peter Denning
+succinctly phrases this rule as
+``The average number of objects in a queue is the product of the
+entry rate and the average holding time.''
+He applies it to his wine cellar:
+``I have 150 cases of wine in my basement and I consume
+(and purchase) 25 cases per year.
+How long do I hold each case?
+Little's Law tells me to divide 150 cases
+by 25 cases/year, which gives 6 years per case.''
+
+
+He then turns to more serious applications.
+``The response-time formula for a multi-user system can be proved
+using Little's Law and flow balance.
+Assume n users of average think time z are connected
+to an arbitrary system with response time r.
+Each user cycles between thinking and waiting-for-response,
+so the total number of jobs in the meta-system
+(consisting of users and the computer system)
+is fixed at n.
+If you cut the path from the system's output to the users,
+you see a meta-system with average load n,
+average response time z+r,
+and throughput x (measured in jobs per time unit).
+Little's Law says n = x*(z+r),
+and solving for r gives r = n/x - z.''
+
+
+ Next: Section 7.5. Principles.
+
+
+
+Copyright © 1999
+Lucent Technologies. All rights reserved.
+
+Mon 9 Aug 1999
+
+
+
diff --git a/sec075.html b/sec075.html
index b682b03..d21d770 100644
--- a/sec075.html
+++ b/sec075.html
@@ -1,39 +1,39 @@
-
-
-
-
-When you use back-of-the-envelope calculations,
-be sure to recall Einstein's famous advice.
- Next: Section 7.6. Problems.
-
-
-
-Copyright © 1999
-Lucent Technologies. All rights reserved.
-
-Mon 9 Aug 1999
-
-
-
+
+
+
+
+When you use back-of-the-envelope calculations,
+be sure to recall Einstein's famous advice.
+ Next: Section 7.6. Problems.
+
+
+
+Copyright © 1999
+Lucent Technologies. All rights reserved.
+
+Mon 9 Aug 1999
+
+
+
diff --git a/sec076.html b/sec076.html
index 8c73b1c..bf5eeba 100644
--- a/sec076.html
+++ b/sec076.html
@@ -1,125 +1,125 @@
-
-
-
-
-The quiz in Appendix 2
-contains additional problems.
-
-
-The
-Solutions to Column 7
-give answers for some of these problems.
-
-
-1. While Bell Labs is about a thousand miles from the
-mighty Mississippi,
-we are only a couple of miles from the
-usually peaceful Passaic River.
-After a particularly heavy week of rains,
-the June 10, 1992, edition of the
-Star-Ledger
-quoted an engineer as saying that
-``the river was traveling about 200 miles per hour,
-about five times faster than average''.
-Any comments?
-
-
-2. At what distances can a courier on a bicycle with
-removable media be a more rapid carrier of information than a
-high-speed data line?
-
-
-3. How long would it take you to fill a floppy disk by typing?
-
-
-4. Suppose the world is slowed down by a factor of a million.
-How long does it take for your computer to execute an instruction?
-Your disk to rotate once?
-Your disk arm to seek across the disk?
-You to type your name?
-
-
-5. Prove why ``casting out nines'' correctly tests addition.
-How can you further test the Rule of 72?
-What can you prove about it?
-
-
-6. A United Nations estimate put the 1998 world population
-at 5.9 billion and the annual growth rate at 1.33 percent.
-Were this rate to continue,
-what would the population be in 2050?
-
-
-7. Appendix 3
-describes programs to produce models
-of the time and space costs of your system.
-After reading about the models,
-write down your guesses for the costs on your system.
-Retrieve the programs from the book's web site,
-run them on your system,
-and compare those estimates to your guesses.
-
-
-8. Use quick calculations to estimate the run time of designs
-sketched in this book.
-
-9. Suppose that a system makes 100 disk accesses
-to process a transaction
-(although some systems need fewer,
-some systems require several hundred
-disk accesses per transaction).
-How many transactions per hour per
-disk can the system handle?
-
-
-10. Estimate your city's death rate,
-measured in percent of population per year.
-
-
-11. [P. J. Denning]
-Sketch a proof of Little's Law.
-
-
-12. You read in a newspaper article that a United States
-quarter-dollar coin has ``an average life of 30 years''.
-How can you check that claim?
-
-
- Next: Section 7.7. Further Reading.
-
-
-
-Copyright © 1999
-Lucent Technologies. All rights reserved.
-
-Mon 9 Aug 1999
-
-
-
+
+
+
+
+The quiz in Appendix 2
+contains additional problems.
+
+
+The
+Solutions to Column 7
+give answers for some of these problems.
+
+
+1. While Bell Labs is about a thousand miles from the
+mighty Mississippi,
+we are only a couple of miles from the
+usually peaceful Passaic River.
+After a particularly heavy week of rains,
+the June 10, 1992, edition of the
+Star-Ledger
+quoted an engineer as saying that
+``the river was traveling about 200 miles per hour,
+about five times faster than average''.
+Any comments?
+
+
+2. At what distances can a courier on a bicycle with
+removable media be a more rapid carrier of information than a
+high-speed data line?
+
+
+3. How long would it take you to fill a floppy disk by typing?
+
+
+4. Suppose the world is slowed down by a factor of a million.
+How long does it take for your computer to execute an instruction?
+Your disk to rotate once?
+Your disk arm to seek across the disk?
+You to type your name?
+
+
+5. Prove why ``casting out nines'' correctly tests addition.
+How can you further test the Rule of 72?
+What can you prove about it?
+
+
+6. A United Nations estimate put the 1998 world population
+at 5.9 billion and the annual growth rate at 1.33 percent.
+Were this rate to continue,
+what would the population be in 2050?
+
+
+7. Appendix 3
+describes programs to produce models
+of the time and space costs of your system.
+After reading about the models,
+write down your guesses for the costs on your system.
+Retrieve the programs from the book's web site,
+run them on your system,
+and compare those estimates to your guesses.
+
+
+8. Use quick calculations to estimate the run time of designs
+sketched in this book.
+
+9. Suppose that a system makes 100 disk accesses
+to process a transaction
+(although some systems need fewer,
+some systems require several hundred
+disk accesses per transaction).
+How many transactions per hour per
+disk can the system handle?
+
+
+10. Estimate your city's death rate,
+measured in percent of population per year.
+
+
+11. [P. J. Denning]
+Sketch a proof of Little's Law.
+
+
+12. You read in a newspaper article that a United States
+quarter-dollar coin has ``an average life of 30 years''.
+How can you check that claim?
+
+
+ Next: Section 7.7. Further Reading.
+
+
+
+Copyright © 1999
+Lucent Technologies. All rights reserved.
+
+Mon 9 Aug 1999
+
+
+
diff --git a/sec077.html b/sec077.html
index a23790a..db0eb4e 100644
--- a/sec077.html
+++ b/sec077.html
@@ -1,68 +1,68 @@
-
-
-
-
-My all-time favorite book on common sense in
-mathematics is Darrel Huff's 1954 classic
-How To Lie With Statistics;
-it was reissued by Norton in 1993.
-The examples are now quaint
-(some of those rich folks make a whopping
-twenty-five thousand dollars per year!),
-but the principles are timeless.
-John Allen Paulos's
-Innumeracy: Mathematical Illiteracy and Its Consequences
-is a 1990 approach to similar problems
-(published by Farrar, Straus and Giroux).
-
-
-Physicists are well aware of this topic.
-After this column appeared in
-Communications of the ACM,
-Jan Wolitzky wrote
- Next: Section 7.8. Quick Calculations in Everyday Life.
-
-
-
-Copyright © 1999
-Lucent Technologies. All rights reserved.
-
-Mon 9 Aug 1999
-
-
-
+
+
+
+
+My all-time favorite book on common sense in
+mathematics is Darrel Huff's 1954 classic
+How To Lie With Statistics;
+it was reissued by Norton in 1993.
+The examples are now quaint
+(some of those rich folks make a whopping
+twenty-five thousand dollars per year!),
+but the principles are timeless.
+John Allen Paulos's
+Innumeracy: Mathematical Illiteracy and Its Consequences
+is a 1990 approach to similar problems
+(published by Farrar, Straus and Giroux).
+
+
+Physicists are well aware of this topic.
+After this column appeared in
+Communications of the ACM,
+Jan Wolitzky wrote
+ Next: Section 7.8. Quick Calculations in Everyday Life.
+
+
+
+Copyright © 1999
+Lucent Technologies. All rights reserved.
+
+Mon 9 Aug 1999
+
+
+
diff --git a/sec078.html b/sec078.html
index 1c69cef..8d4a1f6 100644
--- a/sec078.html
+++ b/sec078.html
@@ -1,98 +1,98 @@
-
-
-
+
+Estimation Answers
+
+
+
(From Appendix 2 of
+
Programming Pearls)
+
+Napoleon was born in 1769.
+
+
+The Mississippi-Missouri river is 3,710 miles long.
+
+
+Maximum takeoff weight of a B747-400 airliner
+is 875,000 pounds.
+
+
+A radio signal travels from the earth to the moon
+in 1.29 seconds.
+
+
+Latitude of London is about 51.5 degrees.
+
+
+A space shuttle orbits the earth in about 91 minutes.
+
+
+4200 feet between the towers of the Golden Gate Bridge.
+
+
+56 signers of the
+Declaration of Independence.
+
+
+206 bones in the adult human body.
+
+
+
+Interpretation
+
+
-
-Cost Models for Time and Space
-
-
-
-
(Appendix 3 of
-
Programming Pearls)
-
-to give precise measurements of primitive objects:
-
-cout << "sizeof(char)=" << sizeof(char);
-cout << " sizeof(short)=" << sizeof(short);
-
-
-
-sizeof(char)=1 sizeof(short)=2 sizeof(int)=4
-sizeof(float)=4 sizeof(struct *)=4 sizeof(long)=4
-sizeof(double)=8
-
-The program uses a macro to report the
-sizeof the structure,
-and then to estimate the number of bytes that
-new allocates in a report like this:
-
-struct structc { char c; };
-struct structic { int i; char c; };
-struct structip { int i; structip *p; };
-struct structdc { double d; char c; };
-struct structc12 { char c[12]; };
-
-The first number is given by sizeof,
-and the next ten numbers report the differences
-between successive pointers returned by new.
-This output is typical:
-most of the numbers are quite consistent,
-but the allocator skips around every now and then.
-
-
-structc 1 48 48 48 48 48 48 48 48 48 48
-structic 8 48 48 48 48 48 48 48 48 48 48
-structip 8 48 48 48 48 48 48 48 48 48 48
-structdc 16 64 64 64 64 64 64 64 64 64 64
-structcd 16 64 64 64 64 64 64 64 64 64 64
-structcdc 24 -3744 4096 64 64 64 64 64 64 64 64
-structiii 12 48 48 48 48 48 48 48 48 48 48
-
-The macro is called with the structure name
-followed by the same name in quotes,
-so it can be printed:
-
-#define MEASURE(T, text) { \
- cout << text << "\t"; \
- cout << sizeof(T) << "\t"; \
- int lastp = 0; \
- for (int i = 0; i < 11; i++) { \
- T *p = new T; \
- int thisp = (int) p; \
- if (lastp != 0) \
- cout << " " << thisp - lastp; \
- lastp = thisp; \
- } \
- cout << "\n"; \
-}
-
-(My first draft used a C++ template
-parameterized by structure type,
-but measurements were led wildly astray by
-artifacts of the C++ implementation.)
-
-
-MEASURE(structc, "structc");
-
-
-
-
-
-
-The left column of numbers helps us to estimate
-the sizeof structures.
-We start by summing the sizeof the types;
-that explains the 8 bytes for structip.
-We must also account for the alignment;
-although its components sum to 10 bytes
-(two chars and a double),
-structcdc consumes 24 bytes.
-
-STRUCTURE sizeof new size int 4 48 structc 1 48 structic 8 48 structip 8 48 structdc 16 64 structcd 16 64 structcdc 24 64 structiii 12 48 structiic 12 48 structc12 12 48 structc13 13 64 structc28 28 64 structc29 29 80
-Those lines (and a few more like them)
-produce this output:
-
-T("Integer Arithmetic");
-M({});
-M(k++);
-M(k = i + j);
-M(k = i - j);
- ...
-
-The first column gives the operation
-that is executed inside the loop
-
-Integer Arithmetic (n=5000)
- {} 250 261 250 250 251 10
- k++ 471 460 471 461 460 19
- k = i + j 491 491 500 491 491 20
- k = i - j 440 441 441 440 441 18
- k = i * j 491 490 491 491 490 20
- k = i / j 2414 2433 2424 2423 2414 97
- k = i % j 2423 2414 2423 2414 2423 97
- k = i & j 491 491 480 491 491 20
- k = i | j 440 441 441 440 441 18
-
-The next five columns show the raw time
-in clock clicks (milliseconds on this system)
-for five executions of that loop
-(these times are all consistent;
-inconsistent numbers help to identify suspicious runs).
-The final column gives the average cost
-in nanoseconds per operation.
-The first row of the table says that it takes
-about ten nanoseconds to execute a loop that
-contains the null operation.
-The next row says that incrementing the variable k
-consumes about 9 additional nanoseconds.
-All of the arithmetic and logical operations have
-about the same cost,
-with the exception of the division and remainder operators,
-which are an order-of-magnitude more expensive.
-
-
-for i = [1, n]
- for j = [1, n]
- op
-
-The complete code for this cost model can be found
-at this book's web site.
-
-
-#define M(op)
- print op as a string
- timesum = 0
- for trial = [0, trials)
- start = clock()
- for i = [1, n]
- fi = i
- for j = [1, n]
- op
- t = clock()-start
- print t
- timesum += t
- print 1e9*timesum / (n*n * trials * CLOCKS_PER_SEC)
-
-The floating point operations originally assign the
-integer j to the floating-point fj
-(in about 8 nanoseconds);
-the outer loop assigns i to the floating-point fi.
-The floating operations themselves cost about as much
-as their integer counterparts,
-and the array operations are equally inexpensive.
-
-
-Floating Point Arithmetic (n=5000)
- fj=j; 18
- fj=j; fk = fi + fj 26
- fj=j; fk = fi - fj 27
- fj=j; fk = fi * fj 24
- fj=j; fk = fi / fj 78
-Array Operations (n=5000)
- k = i + j 17
- k = x[i] + j 18
- k = i + x[j] 24
- k = x[i] + x[j] 27
-
-The function versions of comparing and swapping
-each cost about 20 nanoseconds more
-than their inline counterparts.
-Section 9.2 compares the cost of computing the
-maximum of two values with functions, macros and inline code:
-
-Comparisons (n=5000)
- if (i < j) k++ 20
- if (x[i] < x[j]) k++ 25
-Array Comparisons and Swaps (n=5000)
- k = (x[i]<x[k]) ? -1:1 34
- k = intcmp(x+i, x+j) 52
- swapmac(i, j) 41
- swapfunc(i, j) 65
-
-
-
-Max Function, Macro and Inline (n=5000)
- k = (i > j) ? i : j 26
- k = maxmac(i, j) 26
- k = maxfunc(i, j) 54
-
-Because those are so pricey,
-we shrunk the value of n.
-Memory allocation is more expensive yet,
-and merits an even smaller n:
-
-Math Functions (n=1000)
- k = rand() 40
- fk = j+fi 20
- fk = sqrt(j+fi) 188
- fk = sin(j+fi) 344
- fk = sinh(j+fi) 2229
- fk = asin(j+fi) 973
- fk = cos(j+fi) 353
- fk = tan(j+fi) 465
-
-
-
-
-
-Memory Allocation (n=500)
- free(malloc(16)) 2484
- free(malloc(100)) 3044
- free(malloc(2000)) 4959
-
+
+Cost Models for Time and Space
+
+
+
+
(Appendix 3 of
+
Programming Pearls)
+
+to give precise measurements of primitive objects:
+
+cout << "sizeof(char)=" << sizeof(char);
+cout << " sizeof(short)=" << sizeof(short);
+
+
+
+sizeof(char)=1 sizeof(short)=2 sizeof(int)=4
+sizeof(float)=4 sizeof(struct *)=4 sizeof(long)=4
+sizeof(double)=8
+
+The program uses a macro to report the
+sizeof the structure,
+and then to estimate the number of bytes that
+new allocates in a report like this:
+
+struct structc { char c; };
+struct structic { int i; char c; };
+struct structip { int i; structip *p; };
+struct structdc { double d; char c; };
+struct structc12 { char c[12]; };
+
+The first number is given by sizeof,
+and the next ten numbers report the differences
+between successive pointers returned by new.
+This output is typical:
+most of the numbers are quite consistent,
+but the allocator skips around every now and then.
+
+
+structc 1 48 48 48 48 48 48 48 48 48 48
+structic 8 48 48 48 48 48 48 48 48 48 48
+structip 8 48 48 48 48 48 48 48 48 48 48
+structdc 16 64 64 64 64 64 64 64 64 64 64
+structcd 16 64 64 64 64 64 64 64 64 64 64
+structcdc 24 -3744 4096 64 64 64 64 64 64 64 64
+structiii 12 48 48 48 48 48 48 48 48 48 48
+
+The macro is called with the structure name
+followed by the same name in quotes,
+so it can be printed:
+
+#define MEASURE(T, text) { \
+ cout << text << "\t"; \
+ cout << sizeof(T) << "\t"; \
+ int lastp = 0; \
+ for (int i = 0; i < 11; i++) { \
+ T *p = new T; \
+ int thisp = (int) p; \
+ if (lastp != 0) \
+ cout << " " << thisp - lastp; \
+ lastp = thisp; \
+ } \
+ cout << "\n"; \
+}
+
+(My first draft used a C++ template
+parameterized by structure type,
+but measurements were led wildly astray by
+artifacts of the C++ implementation.)
+
+
+MEASURE(structc, "structc");
+
+
+
+
+
+
+The left column of numbers helps us to estimate
+the sizeof structures.
+We start by summing the sizeof the types;
+that explains the 8 bytes for structip.
+We must also account for the alignment;
+although its components sum to 10 bytes
+(two chars and a double),
+structcdc consumes 24 bytes.
+
+STRUCTURE sizeof new size int 4 48 structc 1 48 structic 8 48 structip 8 48 structdc 16 64 structcd 16 64 structcdc 24 64 structiii 12 48 structiic 12 48 structc12 12 48 structc13 13 64 structc28 28 64 structc29 29 80
+Those lines (and a few more like them)
+produce this output:
+
+T("Integer Arithmetic");
+M({});
+M(k++);
+M(k = i + j);
+M(k = i - j);
+ ...
+
+The first column gives the operation
+that is executed inside the loop
+
+Integer Arithmetic (n=5000)
+ {} 250 261 250 250 251 10
+ k++ 471 460 471 461 460 19
+ k = i + j 491 491 500 491 491 20
+ k = i - j 440 441 441 440 441 18
+ k = i * j 491 490 491 491 490 20
+ k = i / j 2414 2433 2424 2423 2414 97
+ k = i % j 2423 2414 2423 2414 2423 97
+ k = i & j 491 491 480 491 491 20
+ k = i | j 440 441 441 440 441 18
+
+The next five columns show the raw time
+in clock clicks (milliseconds on this system)
+for five executions of that loop
+(these times are all consistent;
+inconsistent numbers help to identify suspicious runs).
+The final column gives the average cost
+in nanoseconds per operation.
+The first row of the table says that it takes
+about ten nanoseconds to execute a loop that
+contains the null operation.
+The next row says that incrementing the variable k
+consumes about 9 additional nanoseconds.
+All of the arithmetic and logical operations have
+about the same cost,
+with the exception of the division and remainder operators,
+which are an order-of-magnitude more expensive.
+
+
+for i = [1, n]
+ for j = [1, n]
+ op
+
+The complete code for this cost model can be found
+at this book's web site.
+
+
+#define M(op)
+ print op as a string
+ timesum = 0
+ for trial = [0, trials)
+ start = clock()
+ for i = [1, n]
+ fi = i
+ for j = [1, n]
+ op
+ t = clock()-start
+ print t
+ timesum += t
+ print 1e9*timesum / (n*n * trials * CLOCKS_PER_SEC)
+
+The floating point operations originally assign the
+integer j to the floating-point fj
+(in about 8 nanoseconds);
+the outer loop assigns i to the floating-point fi.
+The floating operations themselves cost about as much
+as their integer counterparts,
+and the array operations are equally inexpensive.
+
+
+Floating Point Arithmetic (n=5000)
+ fj=j; 18
+ fj=j; fk = fi + fj 26
+ fj=j; fk = fi - fj 27
+ fj=j; fk = fi * fj 24
+ fj=j; fk = fi / fj 78
+Array Operations (n=5000)
+ k = i + j 17
+ k = x[i] + j 18
+ k = i + x[j] 24
+ k = x[i] + x[j] 27
+
+The function versions of comparing and swapping
+each cost about 20 nanoseconds more
+than their inline counterparts.
+Section 9.2 compares the cost of computing the
+maximum of two values with functions, macros and inline code:
+
+Comparisons (n=5000)
+ if (i < j) k++ 20
+ if (x[i] < x[j]) k++ 25
+Array Comparisons and Swaps (n=5000)
+ k = (x[i]<x[k]) ? -1:1 34
+ k = intcmp(x+i, x+j) 52
+ swapmac(i, j) 41
+ swapfunc(i, j) 65
+
+
+
+Max Function, Macro and Inline (n=5000)
+ k = (i > j) ? i : j 26
+ k = maxmac(i, j) 26
+ k = maxfunc(i, j) 54
+
+Because those are so pricey,
+we shrunk the value of n.
+Memory allocation is more expensive yet,
+and merits an even smaller n:
+
+Math Functions (n=1000)
+ k = rand() 40
+ fk = j+fi 20
+ fk = sqrt(j+fi) 188
+ fk = sin(j+fi) 344
+ fk = sinh(j+fi) 2229
+ fk = asin(j+fi) 973
+ fk = cos(j+fi) 353
+ fk = tan(j+fi) 465
+
+
+
+
+
+Memory Allocation (n=500)
+ free(malloc(16)) 2484
+ free(malloc(100)) 3044
+ free(malloc(2000)) 4959
+
-
-Rules for Code Tuning
-
-
-
-
(Appendix 4 of
-
Programming Pearls)
-Space-For-Time Rules
-
-Data Structure Augmentation.
-The time required for common operations on data can often
-be reduced by augmenting the structure with extra information
-or by changing the information within the structure
-so that it can be accessed more easily.
-
-
-Store Precomputed Results.
-The cost of recomputing an expensive function
-can be reduced by computing the function only once
-and storing the results.
-Subsequent requests for the function are then handled
-by table lookup rather than by computing the function.
-
-
-Caching.
-Data that is accessed most often should be
-the cheapest to access.
-
-
-
-Lazy Evaluation.
-The strategy of never evaluating an item until it is needed
-avoids evaluations of unnecessary items.
-
-
-Time-For-Space Rules
-
-Packing.
-Dense storage representations can decrease storage costs
-by increasing the time required to store and retrieve data.
-
-
-Interpreters.
-The space required to represent a program can often
-be decreased by the use of interpreters
-in which
-common sequences of operations are represented compactly.
-
-
-Loop Rules
-
-Code Motion Out of Loops.
-Instead of performing a certain computation
-in each iteration of a loop,
-it is better to perform it only once,
-outside the loop.
-
-
-Combining Tests.
-An efficient inner loop should contain
-as few tests as possible,
-and preferably only one.
-The programmer should therefore try to simulate
-some of the exit conditions of the loop
-by other exit conditions.
-
-
-Loop Unrolling.
-Unrolling a loop can remove the cost of modifying loop indices,
-and also help to avoid pipeline stalls,
-to reduce branches,
-and to increase instruction-level parallelism.
-
-
-Transfer-Driven Loop Unrolling.
-If a large cost of an inner loop
-is devoted to trivial assignments,
-then those assignments can often be removed
-by repeating the code and changing the use of variables.
-Specifically, to remove the assignment i = j,
-the subsequent code must treat j as though it were i.
-
-
-Unconditional Branch Removal.
-A fast loop should contain no unconditional branches.
-An unconditional branch at the end of a loop can be removed
-by ``rotating'' the loop to have a conditional branch
-at the bottom.
-
-
-Loop Fusion.
-If two nearby loops operate on the same set of elements,
-then combine their operational parts
-and use only one set of loop control operations.
-
-
-Logic Rules
-
-Exploit Algebraic Identities.
-If the evaluation of a logical expression is costly,
-replace it by an algebraically equivalent expression
-that is cheaper to evaluate.
-
-
-Short-Circuiting Monotone Functions.
-If we wish to test whether
-some monotone nondecreasing function of several variables
-is over a certain threshold,
-then we need not evaluate any of the variables
-once the threshold has been reached.
-
-
-Reordering Tests.
-Logical tests should be arranged
-such that inexpensive and often successful tests
-precede expensive and rarely successful tests.
-
-
-Precompute Logical Functions.
-A logical function over a small finite domain can be replaced
-by a lookup in a table that represents the domain.
-
-
-Boolean Variable Elimination.
-We can remove boolean variables from a program
-by replacing the assignment to a boolean variable v
-by an if-else statement
-in which one branch represents the case that v is true
-and the other represents the case that v is false.
-
-
-Procedure Rules
-
-Collapsing Function Hierarchies.
-The run times of the elements of a set of functions
-that (nonrecursively) call themselves
-can often be reduced by rewriting functions in line
-and binding the passed variables.
-
-
-Exploit Common Cases.
-Functions should be organized to handle all cases correctly
-and common cases efficiently.
-
-
-Coroutines.
-A multiple-pass algorithm can often be turned into
-a single-pass algorithm by use of coroutines.
-
-
-Transformations on Recursive Functions.
-The run time of recursive functions can often be reduced
-by applying the following transformations:
-
-
-Parallelism.
-
-A program should be structured to exploit
-as much of the
-parallelism as possible in the underlying hardware.
-
-
-Expression Rules
-
-Compile-Time Initialization.
-As many variables as possible should be
-initialized before program execution.
-
-
-Exploit Algebraic Identities.
-If the evaluation of an expression is costly,
-replace it by an algebraically equivalent expression
-that is cheaper to evaluate.
-
-
-Common Subexpression Elimination.
-If the same expression is evaluated twice
-with none of its variables altered between evaluations,
-then the second evaluation can be avoided
-by storing the result of the first
-and using that in place of the second.
-
-
-Pairing Computation.
-If two similar expressions are frequently evaluated together,
-then we should make a new procedure
-that evaluates them as a pair.
-
-
-Exploit Word Parallelism.
-Use the full data-path width of the
-underlying computer architecture
-to evaluate expensive expressions.
-
-
-
-
+
+Rules for Code Tuning
+
+
+
+
(Appendix 4 of
+
Programming Pearls)
+Space-For-Time Rules
+
+Data Structure Augmentation.
+The time required for common operations on data can often
+be reduced by augmenting the structure with extra information
+or by changing the information within the structure
+so that it can be accessed more easily.
+
+
+Store Precomputed Results.
+The cost of recomputing an expensive function
+can be reduced by computing the function only once
+and storing the results.
+Subsequent requests for the function are then handled
+by table lookup rather than by computing the function.
+
+
+Caching.
+Data that is accessed most often should be
+the cheapest to access.
+
+
+
+Lazy Evaluation.
+The strategy of never evaluating an item until it is needed
+avoids evaluations of unnecessary items.
+
+
+Time-For-Space Rules
+
+Packing.
+Dense storage representations can decrease storage costs
+by increasing the time required to store and retrieve data.
+
+
+Interpreters.
+The space required to represent a program can often
+be decreased by the use of interpreters
+in which
+common sequences of operations are represented compactly.
+
+
+Loop Rules
+
+Code Motion Out of Loops.
+Instead of performing a certain computation
+in each iteration of a loop,
+it is better to perform it only once,
+outside the loop.
+
+
+Combining Tests.
+An efficient inner loop should contain
+as few tests as possible,
+and preferably only one.
+The programmer should therefore try to simulate
+some of the exit conditions of the loop
+by other exit conditions.
+
+
+Loop Unrolling.
+Unrolling a loop can remove the cost of modifying loop indices,
+and also help to avoid pipeline stalls,
+to reduce branches,
+and to increase instruction-level parallelism.
+
+
+Transfer-Driven Loop Unrolling.
+If a large cost of an inner loop
+is devoted to trivial assignments,
+then those assignments can often be removed
+by repeating the code and changing the use of variables.
+Specifically, to remove the assignment i = j,
+the subsequent code must treat j as though it were i.
+
+
+Unconditional Branch Removal.
+A fast loop should contain no unconditional branches.
+An unconditional branch at the end of a loop can be removed
+by ``rotating'' the loop to have a conditional branch
+at the bottom.
+
+
+Loop Fusion.
+If two nearby loops operate on the same set of elements,
+then combine their operational parts
+and use only one set of loop control operations.
+
+
+Logic Rules
+
+Exploit Algebraic Identities.
+If the evaluation of a logical expression is costly,
+replace it by an algebraically equivalent expression
+that is cheaper to evaluate.
+
+
+Short-Circuiting Monotone Functions.
+If we wish to test whether
+some monotone nondecreasing function of several variables
+is over a certain threshold,
+then we need not evaluate any of the variables
+once the threshold has been reached.
+
+
+Reordering Tests.
+Logical tests should be arranged
+such that inexpensive and often successful tests
+precede expensive and rarely successful tests.
+
+
+Precompute Logical Functions.
+A logical function over a small finite domain can be replaced
+by a lookup in a table that represents the domain.
+
+
+Boolean Variable Elimination.
+We can remove boolean variables from a program
+by replacing the assignment to a boolean variable v
+by an if-else statement
+in which one branch represents the case that v is true
+and the other represents the case that v is false.
+
+
+Procedure Rules
+
+Collapsing Function Hierarchies.
+The run times of the elements of a set of functions
+that (nonrecursively) call themselves
+can often be reduced by rewriting functions in line
+and binding the passed variables.
+
+
+Exploit Common Cases.
+Functions should be organized to handle all cases correctly
+and common cases efficiently.
+
+
+Coroutines.
+A multiple-pass algorithm can often be turned into
+a single-pass algorithm by use of coroutines.
+
+
+Transformations on Recursive Functions.
+The run time of recursive functions can often be reduced
+by applying the following transformations:
+
+
+Parallelism.
+
+A program should be structured to exploit
+as much of the
+parallelism as possible in the underlying hardware.
+
+
+Expression Rules
+
+Compile-Time Initialization.
+As many variables as possible should be
+initialized before program execution.
+
+
+Exploit Algebraic Identities.
+If the evaluation of an expression is costly,
+replace it by an algebraically equivalent expression
+that is cheaper to evaluate.
+
+
+Common Subexpression Elimination.
+If the same expression is evaluated twice
+with none of its variables altered between evaluations,
+then the second evaluation can be avoided
+by storing the result of the first
+and using that in place of the second.
+
+
+Pairing Computation.
+If two similar expressions are frequently evaluated together,
+then we should make a new procedure
+that evaluates them as a pair.
+
+
+Exploit Word Parallelism.
+Use the full data-path width of the
+underlying computer architecture
+to evaluate expensive expressions.
+
+
+
+
-
-Index to
-
-
-
-
-
Programming Pearls
-
-72, Rule of 69, 74, 203, 216
-
-
-Abrahams, P. W. viii
-
-abstract data types 27, 29, 130, 133-142, 152-155, 158
-
-Adams, J. L. 9, 127
-
-Adriance, N. vii
-
-affix analysis 30, 144, 213
-
-Aho, A. V. vii, 8, 86, 159, 178, 207, 213
-
-airplanes 6, 98, 183-184
-
-algorithm design vi, 11-20, 62, 64, 77-86, 91, 115-122, 127-129, 131, 149-157
-
-algorithms, divide-and-conquer 62, 79-81, 84-85, 116
-
-algorithms, multiple-pass 4-5, 7, 207
-
-algorithms, numerical 182
-
-algorithms, randomizing 13, 120
-
-algorithms, scanning 81, 84
-
-algorithms, selection 18, 123, 181, 212, 223
-
-algorithms, string 15-16, 18-20, 98, 123, 144-146, 161-173, 182, 219, 230-231
-
-algorithms, vector 182
-
-allocation, dynamic 105
-
-allocation, storage 87, 137
-
-anagrams 11, 15-20, 209
-
-analysis, affix 30, 144, 213
-
-analysis, big-oh 62, 78
-
-analysis, retrograde 110
-
-Appel, A. W. 61-65, 91
-
-Apple Macintosh 107
-
-Archimedes 201, 212
-
-arrays 12, 22-23, 25-27, 29, 33-55, 77-86, 91, 100-103, 105, 115-125, 135-138, 142-143, 148, 153, 197, 201-202
-
-arrays, cumulative 79, 84, 203, 217
-
-arrays, sparse 8, 100-103
-
-arrays, suffix 165-173
-
-assembly code 62, 95, 107
-
-assertions 37-41, 48-50
-
-automobiles 7, 9, 66, 85, 202
-
-Awk 171, 213
-
-
-
-back of the envelope 9, 15, 25, 62, 64, 67-76, 78, 127, 145, 176, 183-184
-
-
-background data 3, 15, 18, 25, 87, 125, 144, 176
-
-bags, paper 127
-
-Baird, H. S. vii
-
-Basic 127
-
-Basic, Visual 25, 27-28, 54
-
-Bell, C. G. 65
-
-Bentley, D. T. viii
-
-Bentley, J. C. 125
-
-Berecz, V. 98
-
-Bible, King James 162, 230
-
-big-oh analysis 62, 78
-
-binary search 12-13, 16, 18, 33-55, 92-95, 97-98, 170-172, 181, 201, 203-204, 208-209, 213-214, 219, 230
-
-binary search trees 13, 138-140, 164, 171, 181, 198
-
-binary trees 62, 147
-
-binary trees, implicit 148
-
-bins 88, 141-143, 200, 229
-
-Birthday Paradox 204, 224
-
-Bitmap Sort 5-8, 140-141, 180, 205-207
-
-bitmaps 5-8, 13, 140-141, 145, 199, 207
-
-blocks, conceptual 3, 9, 21-26, 92
-
-Boolean Variable Elimination 193
-
-boring stuff 37-39
-
-bounds, lower 84-85, 204, 217
-
-Boyer, R. S. 85
-
-Bridge, Brooklyn 72
-
-Bridge, Golden Gate 183-184
-
-Bridge, Tacoma Narrows 72
-
-Brooklyn Bridge 72
-
-Brooks, F. P., Jr. v, 29, 99-100, 109-110, 220
-
-bugs, performance 72, 89, 91, 119
-
-Butler, S. 166
-
-Buzen, J. P. 73
-
-
-C 19, 45-55, 87-95, 97, 121, 123-125, 171-172, 177, 206, 224, 231
-
-C++ 27, 45, 90, 121, 123-124, 127, 133-143, 158, 171-172, 177, 185, 197-200, 206, 214, 224, 231
-
-C Standard Library 19, 122, 177, 205, 219
-
-C++ Standard Template Library 121-122, 128, 134, 142, 159, 161-162, 164, 172, 177, 197, 205-206, 219, 230
-
-cache-sensitive code 17, 89, 105, 107, 109, 137, 139, 142, 211, 214
-
-Caching 191
-
-calculators 28
-
-canonical forms 16
-
-Cargill, T. A. 16
-
-casting out nines 69, 74
-
-character classification 98, 219
-
-chess 110-111
-
-children 76
-
-Childress, G. L. viii
-
-classification, character 98, 219
-
-Cleveland, W. S. vii
-
-Cobol 25
-
-code, cache-sensitive 17, 89, 105, 107, 109, 137, 139, 142, 211, 214
-
-Code Motion Out of Loops 192
-
-code tuning 62, 64-65, 87-98, 116, 120-122, 142
-
-codes, Huffman 158, 229
-
-coding style 33, 45, 54-55, 130-131, 155, 177, 214
-
-Coffee Can Problem 42
-
-Collapsing Function Hierarchies 193
-
-collection, garbage 105
-
-Combining Tests 192
-
-common divisors, greatest 17, 209-210
-
-Common Subexpression Elimination 195
-
-Compile-Time Initialization 194
-
-compression, data 104, 109
-
-conceptual blocks 3, 9, 21-26, 92
-
-Condon, J. H. 110
-
-contract, programming by 40
-
-Cormen, T. H. 86
-
-Coroutines 194
-
-correctness proofs see program verification
-
-cost models 70-72, 75, 89, 92, 107-108, 185-189
-
-Coughran, W. M. 178
-
-counts, word 162-164
-
-Coupon Collector's Problem 204, 224
-
-Cox, R. S. viii, 28, 54
-
-cumulative arrays 79, 84, 203, 217
-
-
-data, background 3, 15, 18, 25, 87, 125, 144, 176
-
-data compression 104, 109
-
-data structures see arrays, bitmaps, dictionaries, hashing, heaps, linked lists, matrices, priority queues, search, sparse arrays, trees, vectors
-
-data structures, sparse 100-104
-
-data transmission 9, 74, 99, 103-104, 215
-
-data types, abstract 27, 29, 130, 133-142, 152-155, 158
-
-databases 4, 9, 24, 28-29, 64, 72, 110, 161
-
-date functions 26, 30, 109, 212
-
-de Saint-Exupery, A. 7
-
-
-debugging 12-13, 15, 41, 47-50, 54-57, 72, 87, 117-118, 131, 139
-
-Denning, P. J. vii, 73-75, 216
-
-Dershowitz, N. 213
-
-
-design, algorithm vi, 11-20, 62, 64, 77-86, 91, 115-122, 127-129, 131, 149-157
-
-design levels 59, 61-66, 92, 96, 122
-
-design process 7, 17, 31, 64-65, 67, 72, 83, 100, 106, 129, 144, 175
-
-design space 4-5, 108, 123, 127-130, 145, 176
-
-dictionaries 11, 15, 18-20, 26, 31, 109, 144-146, 161-164, 209
-
-difficentralia 167
-
-Dijkstra, E. W. 144
-
-dimension tests 68
-
-displays, seven-segment 31
-
-divide-and-conquer algorithms 62, 79-81, 84-85, 116
-
-divisors, greatest common 17, 209-210
-
-Dobkin, D. 217
-
-domain-specific languages 28-29
-
-Dromey, R. G. 219
-
-Duff, T. 70, 178
-
-Duncan, R. 178
-
-duplicated substring, longest 165-166, 231
-
-dynamic allocation 105
-
-
-Ecuador 56
-
-Edison, T. A. 18, 212
-
-Einstein, A. 74
-
-
-elegance 6-7, 9, 14-15, 20, 24-25, 65, 68, 81, 92, 99-100, 118, 127, 145, 157, 161, 169, 176, 216, 225
-
-
-engineering techniques see
-back of the envelope,
-background data,
-debugging,
-design,
-elegance,
-problem definition,
-prototypes,
-specifications,
-testing,
-tradeoffs
-
-English 11, 15, 18-20, 26, 30, 109, 144-146, 161-173
-
-equivalence relations 16
-
-experiments 8, 17, 51-53, 82, 89, 95-96, 98, 116, 119, 121, 137, 162, 164, 185-189, 206, 210, 214, 221, 230
-
-Exploit Algebraic Identities 193-194
-
-Exploit Common Cases 194
-
-exponentiation 43
-
-
-factors, safety 72-73
-
-Feldman, S. I. 109, 220
-
-Fermi, E. 75
-
-Fermi problems 75
-
-Fibonacci numbers 1-3, 5, 8, 13, 21, 34, 55, 89, 144
-
-fingerprints 16
-
-Floyd, R. W. 129, 143, 225-226
-
-form letters 23-25, 31
-
-forms, canonical 16
-
-Fortran 102
-
-Fraser, A. G. 178
-
-functions, date 26, 30, 109, 212
-
-functions, trigonometric 91
-
-
-Galloping Gertie 72
-
-garbage collection 105
-
-Gardner, M. 11
-
-Garey, M. R. vii
-
-genetic traits 91
-
-Gibbon, P. 61
-
-Golden Gate Bridge 183-184
-
-Gordon, P. viii
-
-graphical user interfaces 28, 55, 106, 202
-
-greatest common divisors 17, 209-210
-
-Grenander, U. 83
-
-Gries, D. vii, 14, 42-43, 210, 217
-
-Grosse, E. H. vii-viii
-
-
-hand waving 14, 16
-
-harness, test 46
-
-hashing 98, 145, 162-164, 171, 181, 201, 207, 221
-
-Hayes, B. 213
-
-heaps 147-159, 228-230
-
-Heapsort 155-159, 180, 204, 229
-
-Hoare, C. A. R. 50, 116, 223
-
-Holmes, S. 168
-
-Homer 166
-
-Hopcroft, J. E. 8, 86, 207
-
-HTML 28
-
-Huff, D. 75
-
-Huffman codes 158, 229
-
-Huffman, D. A. 158, 229
-
-Hume, A. G. vii
-
-hypertext 27, 29
-
-hyphenation 30
-
-
-Iliad 166
-
-implicit binary trees 148
-
-infinite loops 48
-
-initialization, vector 8, 207
-
-Insertion Sort 115-116, 121, 179, 214
-
-integer remainders 88
-
-interfaces, graphical user 28, 55, 106, 202
-
-interpreters 24, 106-107, 192
-
-invariants 34-42, 148-157
-
-Inventor's Paradox 29
-
-
-Jackson, M. A. 9
-
-Jacob, M. 118
-
-Java 45, 54, 123-124, 171, 202, 224
-
-Jelinski, L. W. vii, 159
-
-Johnson, D. S. vii, 158
-
-Johnson, S. C. vii, 31
-
-Jones, A. K. 63
-
-Juno 166
-
-
-Kadane, J. B. 83
-
-Kentucky legislature 100
-
-Kernighan, B. W. vii-viii, 3, 15, 26, 55, 76, 105, 107, 159, 171, 178, 187, 213-214, 226
-
-Kernighan, M. D. viii
-
-key-indexing search 7, 102, 104, 181, 201, 207
-
-King James Bible 162, 230
-
-Knuth, D. E. 3, 16, 34, 72, 96, 123, 126-129, 131-132, 150, 159, 228
-
-Koestler, A. 127
-
-Kolmogorov, A. M. 72
-
-
-Lagarias, J. C. 213
-
-Lampson, B. W. 66
-
-languages, domain-specific 28-29
-
-languages, programming see Awk, Basic, C, C++, Cobol, Fortran, Pascal, Smalltalk, Tcl, Visual Basic
-
-laziness 17, 23
-
-Lazy Evaluation 192
-
-legislature, Kentucky 100
-
-Lehman, A. S. 76
-
-Lehman, N. V. 76
-
-Leiserson, C. E. 86
-
-Lemons, E. W. 28, 56
-
-Lesk, M. E. 18
-
-letters, form 23-25, 31
-
-levels, design 59, 61-66, 92, 96, 122
-
-Library, C Standard 19, 122, 177, 205, 219
-
-Library, C++ Standard Template 121-122, 128, 134, 142, 159, 161-162, 164, 172, 177, 197, 205-206, 219, 230
-
-light bulbs 18
-
-Linderman, J. P. vii-viii, 221
-
-Lindholm, T. 124
-
-linked lists 15, 88, 101, 136-138, 142-143, 145, 198, 226
-
-Lipton, R. J. 217
-
-lists, linked 15, 88, 101, 136-138, 142-143, 145, 198, 226
-
-Little, J. C. R. 73
-
-Little's Law 73-74, 216
-
-lobsters 76
-
-Lomet, D. B. 98
-
-Lomuto, N. 117, 122, 221
-
-longest duplicated substring 165-166, 231
-
-look at the data see background data
-
-Loop Fusion 193
-
-loop unrolling 91, 94, 192
-
-loops, infinite 48
-
-lower bounds 84-85, 204, 217
-
-Lynn, S. vii
-
-
-Macintosh, Apple 107
-
-macros 89, 188
-
-Maguire, S. 50
-
-Mahaney, S. R. 230
-
-maintainability 6-7, 22, 29, 65-66, 87-88, 92, 94, 96, 102, 107, 142
-
-malloc 70, 87, 97, 101, 189, 218-219, 227
-
-managers 59
-
-maps 91, 100
-
-Markov chain 168
-
-Markov text 167-173, 204, 231
-
-Martin, A. R. viii
-
-Martin, R. L. vii, 56, 59, 67
-
-matrices 18, 85, 100-105, 182
-
-maximum subsequence problem 77-86
-
-McConnell, S. v, viii, 31, 55, 98, 214, 216
-
-McCreight, E. M. 158, 229
-
-McIlroy, M. D. vii-viii, 14, 26, 42, 108, 123, 144-146, 172, 222
-
-McIlroy, P. M. viii
-
-Melville, R. C. vii
-
-Memishian, P. viii, 110
-
-Merge Sort 5-6, 180
-
-Mills, H. D. 14, 210
-
-Minerva 166
-
-Mississippi River 67-70, 74
-
-models, cost 70-72, 75, 89, 92, 107-108, 185-189
-
-monitors see profilers
-
-monkeys 167
-
-Moore, J S. 85
-
-multiple-pass algorithms 4-5, 7, 207
-
-Munro, J. I. 230
-
-Musser, D. R. 209
-
-
-name-value pairs 27, 29
-
-Narasimhan, S. viii
-
-n-body problem 61-63
-
-need for speed 60
-
-needlessly big programs 3, 21-31, 106, 130
-
-new operator 70, 135-143, 155, 185-186, 227
-
-Newell, A. 63
-
-Nievergelt, J. 96
-
-nightspots, popular 73
-
-Nixon, R. M. 144
-
-numbers, prime 103
-
-numbers, random 120, 125-126, 130, 189, 224
-
-numerical algorithms 182
-
-
-Olympic games 67
-
-Oppenheimer, R. 75
-
-optimization, premature 96
-
-overlaying 105, 156
-
-
-Packing 192
-
-Pairing Computation 195
-
-pairs, name-value 27, 29
-
-paper bags 127
-
-Paradox, Inventor's 29
-
-Parallelism 194
-
-Parnas, D. L. 27
-
-partitioning functions 116-123, 221
-
-Pascal 214
-
-Passaic River 74, 215
-
-Paulos, J. A. 75
-
-pencils 208
-
-Penzias, A. A. vii
-
-performance bugs 72, 89, 91, 119
-
-performance requirements 4, 14, 67, 91
-
-Perl 25, 171
-
-permutations 15
-
-Pfalzner, S. 61
-
-phrases 164-173
-
-pigeons 208
-
-Pike, R. viii, 55, 107, 171, 178, 214, 226
-
-ping 72
-
-Pinkham, R. 76
-
-pipelines 18-20
-
-Plauger, P. J. 3, 15, 26
-
-pointer to a pointer 227
-
-Polya, G. 29, 68, 130
-
-popular nightspots 73
-
-portability 29
-
-postconditions 40
-
-Potter, H. 76
-
-Precompute Logical Functions 193
-
-preconditions 40
-
-premature optimization 96
-
-prime numbers 103
-
-priority queues 152-155, 159, 181, 230
-
-Problem, Coffee Can 42
-
-
-problem definition 3, 6, 17, 29, 63, 83, 99-100, 125, 127, 129, 144-145, 176
-
-problem, maximum subsequence 77-86
-
-problem, n-body 61-63
-
-problem, substring searching 164
-
-process, design 7, 17, 31, 64-65, 67, 72, 83, 100, 106, 129, 144, 175
-
-profilers 62, 87-88, 96-97, 108-109
-
-program verification vi, 33-44, 84, 92-95, 117-120, 147-157
-
-programmer time 3, 6, 63, 66, 87-88, 92, 102, 105, 116, 130, 142
-
-programming by contract 40
-
-programming languages see Awk, Basic, C, C++, Cobol, Fortran, Pascal, Smalltalk, Tcl, Visual Basic
-
-programs, needlessly big 3, 21-31, 106, 130
-
-programs, reliable 7, 65, 73, 215
-
-programs, robust 7-8, 50, 65, 99, 120, 143
-
-programs, secure 7, 50, 65
-
-programs, subtle 14, 34, 81, 94, 116, 120, 127, 144-146
-
-
-prototypes 6, 17-18, 46-55, 127, 130, 176
-
-pseudocode 34, 45
-
-Public, J. Q. 23
-
-
-qsort 19, 121-122, 166, 170, 172, 177, 205-206
-
-queues 73
-
-queues, priority 152-155, 159, 181, 230
-
-quick tests 68
-
-Quicksort 4, 116-123, 156, 179, 203, 223
-
-Quito 56
-
-
-Radix Sort 180, 222
-
-random numbers 120, 125-126, 130, 189, 224
-
-random samples 125
-
-random sets 8, 103, 125-143, 182, 206, 224-228
-
-randomizing algorithms 13, 120
-
-records, variable-length 105
-
-recurrence relations 30, 81, 85
-
-Reddy, D. R. 63
-
-Reingold, E. M. 13, 208, 213
-
-relations, equivalence 16
-
-reliable programs 7, 65, 73, 215
-
-remainders, integer 88
-
-Reordering Tests 193
-
-Report Program Generator 28
-
-requirements, performance 4, 14, 67, 91
-
-retrograde analysis 110
-
-reversal, vector 14
-
-Ricker, M. E. viii
-
-Ritchie, D. M. viii, 99, 214
-
-Rivest, R. L. 86
-
-robust programs 7-8, 50, 65, 99, 120, 143
-
-Roebling, J. A. 72-73
-
-roots, square 71, 92, 189
-
-Roper, M. J. vii
-
-rotation, vector 11, 13-15, 17, 209-211
-
-Roueche, B. 57
-
-Rule of 72 69, 74, 203, 216
-
-
-rules of thumb 15, 65, 69-70, 74, 96, 125, 130, 176, 178, 214
-
-run time 6, 8, 12, 17-18, 51-55, 59, 62, 70-72, 82, 87-98, 116, 119, 121, 128, 137, 162, 164, 187-189, 206, 210, 214, 221, 230
-
-
-safety factors 72-73
-
-Saini, A. 209
-
-samples, random 125
-
-Saxe, J. B. 85, 209
-
-scaffolding 45-55, 85, 95
-
-scanning algorithms 81, 84
-
-Scholten, C. 42
-
-Schryer, N. L. 178
-
-search, binary 12-13, 16, 18, 33-55, 92-95, 97-98, 170-172, 181, 201, 203-204, 208-209, 213-214, 219, 230
-
-search, key-indexing 7, 102, 104, 181, 201, 207
-
-search, sequential 12, 18, 43, 90-91, 96, 98, 102, 145-146, 153, 180, 201
-
-search trees, binary 13, 138-140, 164, 171, 181, 198
-
-searching problem, substring 164
-
-secure programs 7, 50, 65
-
-Sedgewick, R. 121-122, 124, 159, 221
-
-selection algorithms 18, 123, 181, 212, 223
-
-Selection Sort 123, 180, 222
-
-sentinels 90, 98, 135-137, 141, 143, 227
-
-sequential search 12, 18, 43, 90-91, 96, 98, 102, 145-146, 153, 180, 201
-
-Sethi, R. vii-viii, 178
-
-sets, random 8, 103, 125-143, 182, 206, 224-228
-
-seven-segment displays 31
-
-Shamos, M. I. 83, 131
-
-Shannon, C. E. 168, 204
-
-Shell, D. L. 123, 223
-
-Shell Sort 123, 180, 223
-
-Shepherd, A. 129
-
-Short-Circuiting Monotone Functions 193
-
-signatures 15-16
-
-simulations 62, 98, 153
-
-site, web vi
-
-Skinger, L. vii
-
-Smalltalk 27
-
-Smith, C. M. viii
-
-software engineering see engineering techniques
-
-Sort, Bitmap 5-8, 140-141, 180, 205-207
-
-sort functions, system 3, 7, 19, 72, 115, 121, 211
-
-Sort, Heap see Heapsort
-
-Sort, Insertion 115-116, 121, 179, 214
-
-Sort, Merge 5-6, 180
-
-Sort, Quick see Quicksort
-
-Sort, Radix 180, 222
-
-Sort, Selection 123, 180, 222
-
-Sort, Shell 123, 180, 223
-
-Soundex 16
-
-space see squeezing space
-
-space, design 4-5, 108, 123, 127-130, 145, 176
-
-sparse arrays 8, 100-103
-
-sparse data structures 100-104
-
-
-specifications 4, 33, 64, 125-126, 133-135, 150-153
-
-speed, need for 60
-
-spots, popular night 73
-
-spreadsheets 28-29
-
-square roots 71, 92, 189
-
-squeezing space 3, 5, 8, 11, 14, 22, 70, 99-111, 128, 144-146, 156
-
-Stanat, D. F. vii
-
-Standard Library, C 19, 122, 177, 205, 219
-
-Steele, G. L., Jr. 95
-
-Steier, R. vii
-
-storage allocation 87, 137
-
-Store Precomputed Results 191
-
-string algorithms 15-16, 18-20, 98, 123, 144-146, 161-173, 182, 219, 230-231
-
-Stroustrup, B. vii
-
-structures, sparse data 100-104
-
-stuff, boring 37-39
-
-substring, longest duplicated 165-166, 231
-
-substring searching problem 164
-
-subtle humor 21
-
-subtle programs 14, 34, 81, 94, 116, 120, 127, 144-146
-
-suffix arrays 165-173
-
-surveys 21, 125
-
-symmetry 14, 26, 36, 38, 80, 93, 103, 105, 110-111, 117, 120, 123, 138-139, 153, 156, 176-177, 201
-
-system sort functions 3, 7, 19, 72, 115, 121, 211
-
-Szymanski, T. G. viii
-
-
-table lookup see search
-
-tables, tax 30, 99-100, 212
-
-Tacoma Narrows Bridge 72
-
-tax tables 30, 99-100, 212
-
-Tcl 27, 54
-
-telephones 3-4, 8, 17, 104-105, 144, 207, 211
-
-termination 37, 39-40, 49-50, 118-119, 202, 213
-
-test harness 46
-
-
-testing 8, 20, 22, 33, 41, 46-54, 65, 72, 87, 103
-
-tests, quick 68
-
-text, Markov 167-173, 204, 231
-
-Thompson, K. L. 15, 99, 110-111
-
-time, programmer 3, 6, 63, 66, 87-88, 92, 102, 105, 116, 130, 142
-
-time, run 6, 8, 12, 17-18, 51-55, 59, 62, 70-72, 82, 87-98, 116, 119, 121, 128, 137, 162, 164, 187-189, 206, 210, 214, 221, 230
-
-Toyama, K. viii
-
-
-tradeoffs 7-8, 103, 105, 108, 153, 176, 221
-
-Transfer-Driven Loop Unrolling 193
-
-Transformations on Recursive Functions 194
-
-transmission, data 9, 74, 99, 103-104, 215
-
-trees 13, 62
-
-trees, binary 62, 147
-
-trees, binary search 13, 138-140, 164, 171, 181, 198
-
-trees, implicit binary 148
-
-Trickey, H. viii
-
-trigonometric functions 91
-
-turnpikes 85
-
-
-Ullman, J. D. 8, 18, 86, 207
-
-Ulysses 166
-
-Unconditional Branch Removal 193
-
-Unix system 99, 107, 176
-
-unrolling, loop 91, 94, 192
-
-user interfaces, graphical 28, 55, 106, 202
-
-
-Van Wyk, C. J. vii-viii, 87-88, 96-97, 124, 143, 187, 218
-
-variable-length records 105
-
-vector algorithms 182
-
-vector initialization 8, 207
-
-vector reversal 14
-
-vector rotation 11, 13-15, 17, 209-211
-
-vectors see arrays
-
-verification, program vi, 33-44, 84, 92-95, 117-120, 147-157
-
-Visual Basic 25, 27-28, 54
-
-voice synthesizer 26
-
-Vyssotsky, V. A. vii, 18, 72-73, 95, 131, 178, 201
-
-
-waving, hand 14, 16
-
-web site vi
-
-Weide, B. W. 73
-
-Weil, R. R. 8, 12
-
-Weinberger, P. J. 68, 159, 213
-
-West Point vii, 127
-
-wine cellars 74
-
-Wolitzky, J. I. 75
-
-word counts 162-164
-
-words 15, 18-20, 161-164
-
-Woronow, A. 129
-
-Wright, M. H. 91
-
-Wulf, W. A. 215
-
-
-Yeager, C. 6
-
-
-Zave, P. vii, 130
-
-
-
-
+
+Index to
+
+
+
+
+
Programming Pearls
+
+72, Rule of 69, 74, 203, 216
+
+
+Abrahams, P. W. viii
+
+abstract data types 27, 29, 130, 133-142, 152-155, 158
+
+Adams, J. L. 9, 127
+
+Adriance, N. vii
+
+affix analysis 30, 144, 213
+
+Aho, A. V. vii, 8, 86, 159, 178, 207, 213
+
+airplanes 6, 98, 183-184
+
+algorithm design vi, 11-20, 62, 64, 77-86, 91, 115-122, 127-129, 131, 149-157
+
+algorithms, divide-and-conquer 62, 79-81, 84-85, 116
+
+algorithms, multiple-pass 4-5, 7, 207
+
+algorithms, numerical 182
+
+algorithms, randomizing 13, 120
+
+algorithms, scanning 81, 84
+
+algorithms, selection 18, 123, 181, 212, 223
+
+algorithms, string 15-16, 18-20, 98, 123, 144-146, 161-173, 182, 219, 230-231
+
+algorithms, vector 182
+
+allocation, dynamic 105
+
+allocation, storage 87, 137
+
+anagrams 11, 15-20, 209
+
+analysis, affix 30, 144, 213
+
+analysis, big-oh 62, 78
+
+analysis, retrograde 110
+
+Appel, A. W. 61-65, 91
+
+Apple Macintosh 107
+
+Archimedes 201, 212
+
+arrays 12, 22-23, 25-27, 29, 33-55, 77-86, 91, 100-103, 105, 115-125, 135-138, 142-143, 148, 153, 197, 201-202
+
+arrays, cumulative 79, 84, 203, 217
+
+arrays, sparse 8, 100-103
+
+arrays, suffix 165-173
+
+assembly code 62, 95, 107
+
+assertions 37-41, 48-50
+
+automobiles 7, 9, 66, 85, 202
+
+Awk 171, 213
+
+
+
+back of the envelope 9, 15, 25, 62, 64, 67-76, 78, 127, 145, 176, 183-184
+
+
+background data 3, 15, 18, 25, 87, 125, 144, 176
+
+bags, paper 127
+
+Baird, H. S. vii
+
+Basic 127
+
+Basic, Visual 25, 27-28, 54
+
+Bell, C. G. 65
+
+Bentley, D. T. viii
+
+Bentley, J. C. 125
+
+Berecz, V. 98
+
+Bible, King James 162, 230
+
+big-oh analysis 62, 78
+
+binary search 12-13, 16, 18, 33-55, 92-95, 97-98, 170-172, 181, 201, 203-204, 208-209, 213-214, 219, 230
+
+binary search trees 13, 138-140, 164, 171, 181, 198
+
+binary trees 62, 147
+
+binary trees, implicit 148
+
+bins 88, 141-143, 200, 229
+
+Birthday Paradox 204, 224
+
+Bitmap Sort 5-8, 140-141, 180, 205-207
+
+bitmaps 5-8, 13, 140-141, 145, 199, 207
+
+blocks, conceptual 3, 9, 21-26, 92
+
+Boolean Variable Elimination 193
+
+boring stuff 37-39
+
+bounds, lower 84-85, 204, 217
+
+Boyer, R. S. 85
+
+Bridge, Brooklyn 72
+
+Bridge, Golden Gate 183-184
+
+Bridge, Tacoma Narrows 72
+
+Brooklyn Bridge 72
+
+Brooks, F. P., Jr. v, 29, 99-100, 109-110, 220
+
+bugs, performance 72, 89, 91, 119
+
+Butler, S. 166
+
+Buzen, J. P. 73
+
+
+C 19, 45-55, 87-95, 97, 121, 123-125, 171-172, 177, 206, 224, 231
+
+C++ 27, 45, 90, 121, 123-124, 127, 133-143, 158, 171-172, 177, 185, 197-200, 206, 214, 224, 231
+
+C Standard Library 19, 122, 177, 205, 219
+
+C++ Standard Template Library 121-122, 128, 134, 142, 159, 161-162, 164, 172, 177, 197, 205-206, 219, 230
+
+cache-sensitive code 17, 89, 105, 107, 109, 137, 139, 142, 211, 214
+
+Caching 191
+
+calculators 28
+
+canonical forms 16
+
+Cargill, T. A. 16
+
+casting out nines 69, 74
+
+character classification 98, 219
+
+chess 110-111
+
+children 76
+
+Childress, G. L. viii
+
+classification, character 98, 219
+
+Cleveland, W. S. vii
+
+Cobol 25
+
+code, cache-sensitive 17, 89, 105, 107, 109, 137, 139, 142, 211, 214
+
+Code Motion Out of Loops 192
+
+code tuning 62, 64-65, 87-98, 116, 120-122, 142
+
+codes, Huffman 158, 229
+
+coding style 33, 45, 54-55, 130-131, 155, 177, 214
+
+Coffee Can Problem 42
+
+Collapsing Function Hierarchies 193
+
+collection, garbage 105
+
+Combining Tests 192
+
+common divisors, greatest 17, 209-210
+
+Common Subexpression Elimination 195
+
+Compile-Time Initialization 194
+
+compression, data 104, 109
+
+conceptual blocks 3, 9, 21-26, 92
+
+Condon, J. H. 110
+
+contract, programming by 40
+
+Cormen, T. H. 86
+
+Coroutines 194
+
+correctness proofs see program verification
+
+cost models 70-72, 75, 89, 92, 107-108, 185-189
+
+Coughran, W. M. 178
+
+counts, word 162-164
+
+Coupon Collector's Problem 204, 224
+
+Cox, R. S. viii, 28, 54
+
+cumulative arrays 79, 84, 203, 217
+
+
+data, background 3, 15, 18, 25, 87, 125, 144, 176
+
+data compression 104, 109
+
+data structures see arrays, bitmaps, dictionaries, hashing, heaps, linked lists, matrices, priority queues, search, sparse arrays, trees, vectors
+
+data structures, sparse 100-104
+
+data transmission 9, 74, 99, 103-104, 215
+
+data types, abstract 27, 29, 130, 133-142, 152-155, 158
+
+databases 4, 9, 24, 28-29, 64, 72, 110, 161
+
+date functions 26, 30, 109, 212
+
+de Saint-Exupery, A. 7
+
+
+debugging 12-13, 15, 41, 47-50, 54-57, 72, 87, 117-118, 131, 139
+
+Denning, P. J. vii, 73-75, 216
+
+Dershowitz, N. 213
+
+
+design, algorithm vi, 11-20, 62, 64, 77-86, 91, 115-122, 127-129, 131, 149-157
+
+design levels 59, 61-66, 92, 96, 122
+
+design process 7, 17, 31, 64-65, 67, 72, 83, 100, 106, 129, 144, 175
+
+design space 4-5, 108, 123, 127-130, 145, 176
+
+dictionaries 11, 15, 18-20, 26, 31, 109, 144-146, 161-164, 209
+
+difficentralia 167
+
+Dijkstra, E. W. 144
+
+dimension tests 68
+
+displays, seven-segment 31
+
+divide-and-conquer algorithms 62, 79-81, 84-85, 116
+
+divisors, greatest common 17, 209-210
+
+Dobkin, D. 217
+
+domain-specific languages 28-29
+
+Dromey, R. G. 219
+
+Duff, T. 70, 178
+
+Duncan, R. 178
+
+duplicated substring, longest 165-166, 231
+
+dynamic allocation 105
+
+
+Ecuador 56
+
+Edison, T. A. 18, 212
+
+Einstein, A. 74
+
+
+elegance 6-7, 9, 14-15, 20, 24-25, 65, 68, 81, 92, 99-100, 118, 127, 145, 157, 161, 169, 176, 216, 225
+
+
+engineering techniques see
+back of the envelope,
+background data,
+debugging,
+design,
+elegance,
+problem definition,
+prototypes,
+specifications,
+testing,
+tradeoffs
+
+English 11, 15, 18-20, 26, 30, 109, 144-146, 161-173
+
+equivalence relations 16
+
+experiments 8, 17, 51-53, 82, 89, 95-96, 98, 116, 119, 121, 137, 162, 164, 185-189, 206, 210, 214, 221, 230
+
+Exploit Algebraic Identities 193-194
+
+Exploit Common Cases 194
+
+exponentiation 43
+
+
+factors, safety 72-73
+
+Feldman, S. I. 109, 220
+
+Fermi, E. 75
+
+Fermi problems 75
+
+Fibonacci numbers 1-3, 5, 8, 13, 21, 34, 55, 89, 144
+
+fingerprints 16
+
+Floyd, R. W. 129, 143, 225-226
+
+form letters 23-25, 31
+
+forms, canonical 16
+
+Fortran 102
+
+Fraser, A. G. 178
+
+functions, date 26, 30, 109, 212
+
+functions, trigonometric 91
+
+
+Galloping Gertie 72
+
+garbage collection 105
+
+Gardner, M. 11
+
+Garey, M. R. vii
+
+genetic traits 91
+
+Gibbon, P. 61
+
+Golden Gate Bridge 183-184
+
+Gordon, P. viii
+
+graphical user interfaces 28, 55, 106, 202
+
+greatest common divisors 17, 209-210
+
+Grenander, U. 83
+
+Gries, D. vii, 14, 42-43, 210, 217
+
+Grosse, E. H. vii-viii
+
+
+hand waving 14, 16
+
+harness, test 46
+
+hashing 98, 145, 162-164, 171, 181, 201, 207, 221
+
+Hayes, B. 213
+
+heaps 147-159, 228-230
+
+Heapsort 155-159, 180, 204, 229
+
+Hoare, C. A. R. 50, 116, 223
+
+Holmes, S. 168
+
+Homer 166
+
+Hopcroft, J. E. 8, 86, 207
+
+HTML 28
+
+Huff, D. 75
+
+Huffman codes 158, 229
+
+Huffman, D. A. 158, 229
+
+Hume, A. G. vii
+
+hypertext 27, 29
+
+hyphenation 30
+
+
+Iliad 166
+
+implicit binary trees 148
+
+infinite loops 48
+
+initialization, vector 8, 207
+
+Insertion Sort 115-116, 121, 179, 214
+
+integer remainders 88
+
+interfaces, graphical user 28, 55, 106, 202
+
+interpreters 24, 106-107, 192
+
+invariants 34-42, 148-157
+
+Inventor's Paradox 29
+
+
+Jackson, M. A. 9
+
+Jacob, M. 118
+
+Java 45, 54, 123-124, 171, 202, 224
+
+Jelinski, L. W. vii, 159
+
+Johnson, D. S. vii, 158
+
+Johnson, S. C. vii, 31
+
+Jones, A. K. 63
+
+Juno 166
+
+
+Kadane, J. B. 83
+
+Kentucky legislature 100
+
+Kernighan, B. W. vii-viii, 3, 15, 26, 55, 76, 105, 107, 159, 171, 178, 187, 213-214, 226
+
+Kernighan, M. D. viii
+
+key-indexing search 7, 102, 104, 181, 201, 207
+
+King James Bible 162, 230
+
+Knuth, D. E. 3, 16, 34, 72, 96, 123, 126-129, 131-132, 150, 159, 228
+
+Koestler, A. 127
+
+Kolmogorov, A. M. 72
+
+
+Lagarias, J. C. 213
+
+Lampson, B. W. 66
+
+languages, domain-specific 28-29
+
+languages, programming see Awk, Basic, C, C++, Cobol, Fortran, Pascal, Smalltalk, Tcl, Visual Basic
+
+laziness 17, 23
+
+Lazy Evaluation 192
+
+legislature, Kentucky 100
+
+Lehman, A. S. 76
+
+Lehman, N. V. 76
+
+Leiserson, C. E. 86
+
+Lemons, E. W. 28, 56
+
+Lesk, M. E. 18
+
+letters, form 23-25, 31
+
+levels, design 59, 61-66, 92, 96, 122
+
+Library, C Standard 19, 122, 177, 205, 219
+
+Library, C++ Standard Template 121-122, 128, 134, 142, 159, 161-162, 164, 172, 177, 197, 205-206, 219, 230
+
+light bulbs 18
+
+Linderman, J. P. vii-viii, 221
+
+Lindholm, T. 124
+
+linked lists 15, 88, 101, 136-138, 142-143, 145, 198, 226
+
+Lipton, R. J. 217
+
+lists, linked 15, 88, 101, 136-138, 142-143, 145, 198, 226
+
+Little, J. C. R. 73
+
+Little's Law 73-74, 216
+
+lobsters 76
+
+Lomet, D. B. 98
+
+Lomuto, N. 117, 122, 221
+
+longest duplicated substring 165-166, 231
+
+look at the data see background data
+
+Loop Fusion 193
+
+loop unrolling 91, 94, 192
+
+loops, infinite 48
+
+lower bounds 84-85, 204, 217
+
+Lynn, S. vii
+
+
+Macintosh, Apple 107
+
+macros 89, 188
+
+Maguire, S. 50
+
+Mahaney, S. R. 230
+
+maintainability 6-7, 22, 29, 65-66, 87-88, 92, 94, 96, 102, 107, 142
+
+malloc 70, 87, 97, 101, 189, 218-219, 227
+
+managers 59
+
+maps 91, 100
+
+Markov chain 168
+
+Markov text 167-173, 204, 231
+
+Martin, A. R. viii
+
+Martin, R. L. vii, 56, 59, 67
+
+matrices 18, 85, 100-105, 182
+
+maximum subsequence problem 77-86
+
+McConnell, S. v, viii, 31, 55, 98, 214, 216
+
+McCreight, E. M. 158, 229
+
+McIlroy, M. D. vii-viii, 14, 26, 42, 108, 123, 144-146, 172, 222
+
+McIlroy, P. M. viii
+
+Melville, R. C. vii
+
+Memishian, P. viii, 110
+
+Merge Sort 5-6, 180
+
+Mills, H. D. 14, 210
+
+Minerva 166
+
+Mississippi River 67-70, 74
+
+models, cost 70-72, 75, 89, 92, 107-108, 185-189
+
+monitors see profilers
+
+monkeys 167
+
+Moore, J S. 85
+
+multiple-pass algorithms 4-5, 7, 207
+
+Munro, J. I. 230
+
+Musser, D. R. 209
+
+
+name-value pairs 27, 29
+
+Narasimhan, S. viii
+
+n-body problem 61-63
+
+need for speed 60
+
+needlessly big programs 3, 21-31, 106, 130
+
+new operator 70, 135-143, 155, 185-186, 227
+
+Newell, A. 63
+
+Nievergelt, J. 96
+
+nightspots, popular 73
+
+Nixon, R. M. 144
+
+numbers, prime 103
+
+numbers, random 120, 125-126, 130, 189, 224
+
+numerical algorithms 182
+
+
+Olympic games 67
+
+Oppenheimer, R. 75
+
+optimization, premature 96
+
+overlaying 105, 156
+
+
+Packing 192
+
+Pairing Computation 195
+
+pairs, name-value 27, 29
+
+paper bags 127
+
+Paradox, Inventor's 29
+
+Parallelism 194
+
+Parnas, D. L. 27
+
+partitioning functions 116-123, 221
+
+Pascal 214
+
+Passaic River 74, 215
+
+Paulos, J. A. 75
+
+pencils 208
+
+Penzias, A. A. vii
+
+performance bugs 72, 89, 91, 119
+
+performance requirements 4, 14, 67, 91
+
+Perl 25, 171
+
+permutations 15
+
+Pfalzner, S. 61
+
+phrases 164-173
+
+pigeons 208
+
+Pike, R. viii, 55, 107, 171, 178, 214, 226
+
+ping 72
+
+Pinkham, R. 76
+
+pipelines 18-20
+
+Plauger, P. J. 3, 15, 26
+
+pointer to a pointer 227
+
+Polya, G. 29, 68, 130
+
+popular nightspots 73
+
+portability 29
+
+postconditions 40
+
+Potter, H. 76
+
+Precompute Logical Functions 193
+
+preconditions 40
+
+premature optimization 96
+
+prime numbers 103
+
+priority queues 152-155, 159, 181, 230
+
+Problem, Coffee Can 42
+
+
+problem definition 3, 6, 17, 29, 63, 83, 99-100, 125, 127, 129, 144-145, 176
+
+problem, maximum subsequence 77-86
+
+problem, n-body 61-63
+
+problem, substring searching 164
+
+process, design 7, 17, 31, 64-65, 67, 72, 83, 100, 106, 129, 144, 175
+
+profilers 62, 87-88, 96-97, 108-109
+
+program verification vi, 33-44, 84, 92-95, 117-120, 147-157
+
+programmer time 3, 6, 63, 66, 87-88, 92, 102, 105, 116, 130, 142
+
+programming by contract 40
+
+programming languages see Awk, Basic, C, C++, Cobol, Fortran, Pascal, Smalltalk, Tcl, Visual Basic
+
+programs, needlessly big 3, 21-31, 106, 130
+
+programs, reliable 7, 65, 73, 215
+
+programs, robust 7-8, 50, 65, 99, 120, 143
+
+programs, secure 7, 50, 65
+
+programs, subtle 14, 34, 81, 94, 116, 120, 127, 144-146
+
+
+prototypes 6, 17-18, 46-55, 127, 130, 176
+
+pseudocode 34, 45
+
+Public, J. Q. 23
+
+
+qsort 19, 121-122, 166, 170, 172, 177, 205-206
+
+queues 73
+
+queues, priority 152-155, 159, 181, 230
+
+quick tests 68
+
+Quicksort 4, 116-123, 156, 179, 203, 223
+
+Quito 56
+
+
+Radix Sort 180, 222
+
+random numbers 120, 125-126, 130, 189, 224
+
+random samples 125
+
+random sets 8, 103, 125-143, 182, 206, 224-228
+
+randomizing algorithms 13, 120
+
+records, variable-length 105
+
+recurrence relations 30, 81, 85
+
+Reddy, D. R. 63
+
+Reingold, E. M. 13, 208, 213
+
+relations, equivalence 16
+
+reliable programs 7, 65, 73, 215
+
+remainders, integer 88
+
+Reordering Tests 193
+
+Report Program Generator 28
+
+requirements, performance 4, 14, 67, 91
+
+retrograde analysis 110
+
+reversal, vector 14
+
+Ricker, M. E. viii
+
+Ritchie, D. M. viii, 99, 214
+
+Rivest, R. L. 86
+
+robust programs 7-8, 50, 65, 99, 120, 143
+
+Roebling, J. A. 72-73
+
+roots, square 71, 92, 189
+
+Roper, M. J. vii
+
+rotation, vector 11, 13-15, 17, 209-211
+
+Roueche, B. 57
+
+Rule of 72 69, 74, 203, 216
+
+
+rules of thumb 15, 65, 69-70, 74, 96, 125, 130, 176, 178, 214
+
+run time 6, 8, 12, 17-18, 51-55, 59, 62, 70-72, 82, 87-98, 116, 119, 121, 128, 137, 162, 164, 187-189, 206, 210, 214, 221, 230
+
+
+safety factors 72-73
+
+Saini, A. 209
+
+samples, random 125
+
+Saxe, J. B. 85, 209
+
+scaffolding 45-55, 85, 95
+
+scanning algorithms 81, 84
+
+Scholten, C. 42
+
+Schryer, N. L. 178
+
+search, binary 12-13, 16, 18, 33-55, 92-95, 97-98, 170-172, 181, 201, 203-204, 208-209, 213-214, 219, 230
+
+search, key-indexing 7, 102, 104, 181, 201, 207
+
+search, sequential 12, 18, 43, 90-91, 96, 98, 102, 145-146, 153, 180, 201
+
+search trees, binary 13, 138-140, 164, 171, 181, 198
+
+searching problem, substring 164
+
+secure programs 7, 50, 65
+
+Sedgewick, R. 121-122, 124, 159, 221
+
+selection algorithms 18, 123, 181, 212, 223
+
+Selection Sort 123, 180, 222
+
+sentinels 90, 98, 135-137, 141, 143, 227
+
+sequential search 12, 18, 43, 90-91, 96, 98, 102, 145-146, 153, 180, 201
+
+Sethi, R. vii-viii, 178
+
+sets, random 8, 103, 125-143, 182, 206, 224-228
+
+seven-segment displays 31
+
+Shamos, M. I. 83, 131
+
+Shannon, C. E. 168, 204
+
+Shell, D. L. 123, 223
+
+Shell Sort 123, 180, 223
+
+Shepherd, A. 129
+
+Short-Circuiting Monotone Functions 193
+
+signatures 15-16
+
+simulations 62, 98, 153
+
+site, web vi
+
+Skinger, L. vii
+
+Smalltalk 27
+
+Smith, C. M. viii
+
+software engineering see engineering techniques
+
+Sort, Bitmap 5-8, 140-141, 180, 205-207
+
+sort functions, system 3, 7, 19, 72, 115, 121, 211
+
+Sort, Heap see Heapsort
+
+Sort, Insertion 115-116, 121, 179, 214
+
+Sort, Merge 5-6, 180
+
+Sort, Quick see Quicksort
+
+Sort, Radix 180, 222
+
+Sort, Selection 123, 180, 222
+
+Sort, Shell 123, 180, 223
+
+Soundex 16
+
+space see squeezing space
+
+space, design 4-5, 108, 123, 127-130, 145, 176
+
+sparse arrays 8, 100-103
+
+sparse data structures 100-104
+
+
+specifications 4, 33, 64, 125-126, 133-135, 150-153
+
+speed, need for 60
+
+spots, popular night 73
+
+spreadsheets 28-29
+
+square roots 71, 92, 189
+
+squeezing space 3, 5, 8, 11, 14, 22, 70, 99-111, 128, 144-146, 156
+
+Stanat, D. F. vii
+
+Standard Library, C 19, 122, 177, 205, 219
+
+Steele, G. L., Jr. 95
+
+Steier, R. vii
+
+storage allocation 87, 137
+
+Store Precomputed Results 191
+
+string algorithms 15-16, 18-20, 98, 123, 144-146, 161-173, 182, 219, 230-231
+
+Stroustrup, B. vii
+
+structures, sparse data 100-104
+
+stuff, boring 37-39
+
+substring, longest duplicated 165-166, 231
+
+substring searching problem 164
+
+subtle humor 21
+
+subtle programs 14, 34, 81, 94, 116, 120, 127, 144-146
+
+suffix arrays 165-173
+
+surveys 21, 125
+
+symmetry 14, 26, 36, 38, 80, 93, 103, 105, 110-111, 117, 120, 123, 138-139, 153, 156, 176-177, 201
+
+system sort functions 3, 7, 19, 72, 115, 121, 211
+
+Szymanski, T. G. viii
+
+
+table lookup see search
+
+tables, tax 30, 99-100, 212
+
+Tacoma Narrows Bridge 72
+
+tax tables 30, 99-100, 212
+
+Tcl 27, 54
+
+telephones 3-4, 8, 17, 104-105, 144, 207, 211
+
+termination 37, 39-40, 49-50, 118-119, 202, 213
+
+test harness 46
+
+
+testing 8, 20, 22, 33, 41, 46-54, 65, 72, 87, 103
+
+tests, quick 68
+
+text, Markov 167-173, 204, 231
+
+Thompson, K. L. 15, 99, 110-111
+
+time, programmer 3, 6, 63, 66, 87-88, 92, 102, 105, 116, 130, 142
+
+time, run 6, 8, 12, 17-18, 51-55, 59, 62, 70-72, 82, 87-98, 116, 119, 121, 128, 137, 162, 164, 187-189, 206, 210, 214, 221, 230
+
+Toyama, K. viii
+
+
+tradeoffs 7-8, 103, 105, 108, 153, 176, 221
+
+Transfer-Driven Loop Unrolling 193
+
+Transformations on Recursive Functions 194
+
+transmission, data 9, 74, 99, 103-104, 215
+
+trees 13, 62
+
+trees, binary 62, 147
+
+trees, binary search 13, 138-140, 164, 171, 181, 198
+
+trees, implicit binary 148
+
+Trickey, H. viii
+
+trigonometric functions 91
+
+turnpikes 85
+
+
+Ullman, J. D. 8, 18, 86, 207
+
+Ulysses 166
+
+Unconditional Branch Removal 193
+
+Unix system 99, 107, 176
+
+unrolling, loop 91, 94, 192
+
+user interfaces, graphical 28, 55, 106, 202
+
+
+Van Wyk, C. J. vii-viii, 87-88, 96-97, 124, 143, 187, 218
+
+variable-length records 105
+
+vector algorithms 182
+
+vector initialization 8, 207
+
+vector reversal 14
+
+vector rotation 11, 13-15, 17, 209-211
+
+vectors see arrays
+
+verification, program vi, 33-44, 84, 92-95, 117-120, 147-157
+
+Visual Basic 25, 27-28, 54
+
+voice synthesizer 26
+
+Vyssotsky, V. A. vii, 18, 72-73, 95, 131, 178, 201
+
+
+waving, hand 14, 16
+
+web site vi
+
+Weide, B. W. 73
+
+Weil, R. R. 8, 12
+
+Weinberger, P. J. 68, 159, 213
+
+West Point vii, 127
+
+wine cellars 74
+
+Wolitzky, J. I. 75
+
+word counts 162-164
+
+words 15, 18-20, 161-164
+
+Woronow, A. 129
+
+Wright, M. H. 91
+
+Wulf, W. A. 215
+
+
+Yeager, C. 6
+
+
+Zave, P. vii, 130
+
+
+
+
-
-The Back of the Envelope
-
-
-
(Column 7 of
-Programming Pearls)
-A Story
-
-
-
-
- 1 mile x 1/250 mile x 120 miles/day
- ~
- 1/2 mile3/day
-
-
-showed that the river discharged about
-half a cubic mile of water per day,
-to within an order of magnitude.
-But so what?
-
-The Rest of the Column
-
-
7.1 Basic Skills
-
7.2 Performance Estimates
-
7.3 Safety Factors
-
7.4 Little's Law
-
7.5 Principles
-
7.6 Problems
-
7.7 Further Reading
-
7.8 Quick Calculations in Everyday Life
-
-
-Related Content
-
-
+
+The Back of the Envelope
+
+
+
(Column 7 of
+Programming Pearls)
+A Story
+
+
+
+
+ 1 mile x 1/250 mile x 120 miles/day
+ ~
+ 1/2 mile3/day
+
+
+showed that the river discharged about
+half a cubic mile of water per day,
+to within an order of magnitude.
+But so what?
+
+The Rest of the Column
+
+
7.1 Basic Skills
+
7.2 Performance Estimates
+
7.3 Safety Factors
+
7.4 Little's Law
+
7.5 Principles
+
7.6 Problems
+
7.7 Further Reading
+
7.8 Quick Calculations in Everyday Life
+
+
+Related Content
+
+
-
-Code from
-
-
-
Programming Pearls
-
-
-You may use this code for any purpose, as long as you
-leave the copyright notice and book citation attached.
-
-
-
bitsort.c -- Sort with bit vectors.
-
sortints.cpp -- Sort using C++ STL sets.
-
qsortints.c -- Sort with C library qsort.
-
bitsortgen.c -- Generate random integers for sorting.
-
-
-
-
rotate.c -- Three ways to rotate the elements of a vector.
-
The next two program are used in a pipeline to compute all anagrams in a dictionary
-
sign.c -- Sign each word by its letters in sorted order.
-
squash.c -- Put each anagram class on a single line.
-
-
-
-
search.c -- Linear and binary search.
-
-
-
-
timemod0.c -- Edit main to time one operation.
-
-
-
-
maxsum.c -- Time four algs: n3, n2, n log n, n.
-
-
-
-
genbins.c -- Profile this, then try a special-purpose allocator.
-
macfun.c -- Time the cost of macros and functions.
-
The column also uses rotate.c (Column 2), search.c (Column 5) and maxsum.c (Column 8).
-
-
-
-
sort.cpp -- Mostly C, but also C++ sort function.
-
SortAnim.java -- Animate those sort functions in Java.
-
-
-
-
sortedrand.cpp -- Several algorithms for the task.
-
-
-
-
sets.cpp -- Several data structures for sets.
-
genbins.c (Column 9) implements the bin data structure in C.
-
-
-
-
priqueue.cpp -- Implement and test priority queues.
-
The column also uses sort.c (Column 11) for heapsort.
-
-
-
-
wordlist.cpp -- List words in the file, using STL set.
-
wordfreq.cpp -- List words in the file, with counts, using STL map.
-
wordfreq.c -- Same as above, with hash table in C.
-
longdup.c -- Find long repeated strings in input.
-
markov.c -- Generate random text from input.
-
markovhash.c -- Like markov.c, but with hashing.
-
markovlet.c -- Letter-level markov text, simple algorithm.
-
-
-
spacemod.cpp -- Space used by various records.
-
timemod.c -- Table of times used by various C constructs.
-
-
-
+
+Code from
+
+
+
Programming Pearls
+
+
+You may use this code for any purpose, as long as you
+leave the copyright notice and book citation attached.
+
+
+
bitsort.c -- Sort with bit vectors.
+
sortints.cpp -- Sort using C++ STL sets.
+
qsortints.c -- Sort with C library qsort.
+
bitsortgen.c -- Generate random integers for sorting.
+
+
+
+
rotate.c -- Three ways to rotate the elements of a vector.
+
The next two program are used in a pipeline to compute all anagrams in a dictionary
+
sign.c -- Sign each word by its letters in sorted order.
+
squash.c -- Put each anagram class on a single line.
+
+
+
+
search.c -- Linear and binary search.
+
+
+
+
timemod0.c -- Edit main to time one operation.
+
+
+
+
maxsum.c -- Time four algs: n3, n2, n log n, n.
+
+
+
+
genbins.c -- Profile this, then try a special-purpose allocator.
+
macfun.c -- Time the cost of macros and functions.
+
The column also uses rotate.c (Column 2), search.c (Column 5) and maxsum.c (Column 8).
+
+
+
+
sort.cpp -- Mostly C, but also C++ sort function.
+
SortAnim.java -- Animate those sort functions in Java.
+
+
+
+
sortedrand.cpp -- Several algorithms for the task.
+
+
+
+
sets.cpp -- Several data structures for sets.
+
genbins.c (Column 9) implements the bin data structure in C.
+
+
+
+
priqueue.cpp -- Implement and test priority queues.
+
The column also uses sort.c (Column 11) for heapsort.
+
+
+
+
wordlist.cpp -- List words in the file, using STL set.
+
wordfreq.cpp -- List words in the file, with counts, using STL map.
+
wordfreq.c -- Same as above, with hash table in C.
+
longdup.c -- Find long repeated strings in input.
+
markov.c -- Generate random text from input.
+
markovhash.c -- Like markov.c, but with hashing.
+
markovlet.c -- Letter-level markov text, simple algorithm.
+
+
+
spacemod.cpp -- Space used by various records.
+
timemod.c -- Table of times used by various C constructs.
+
+
+
-
-Cracking the Oyster
-
-
-
(Column 1 of
-Programming Pearls)
-1.1 A Friendly Conversation
-
-
-
-
-The Rest of the Column
-
-
1.2 Precise Problem Statement
-
1.3 Program Design
-
1.4 Implementation Sketch
-
1.5 Principles
-
1.6 Problems
-
1.7 Further Reading
-
-
+
+Cracking the Oyster
+
+
+
(Column 1 of
+Programming Pearls)
+1.1 A Friendly Conversation
+
+
+
+
+The Rest of the Column
+
+
1.2 Precise Problem Statement
+
1.3 Program Design
+
1.4 Implementation Sketch
+
1.5 Principles
+
1.6 Problems
+
1.7 Further Reading
+
+
-
-Epilog to the First Edition of
-
-
-
Programming Pearls
-The points were originally discussed
-in the context of programming,
-but they apply to any engineering endeavor.
-
-
Explore the design space of solutions.
-
Look at the data.
-
Use the back of the envelope.
-
Exploit symmetry.
-
Design with components.
-
Build prototypes.
-
Make tradeoffs when you have to.
-
Keep it simple.
-
Strive for elegance.
-
+
+Epilog to the First Edition of
+
+
+
Programming Pearls
+The points were originally discussed
+in the context of programming,
+but they apply to any engineering endeavor.
+
+
Explore the design space of solutions.
+
Look at the data.
+
Use the back of the envelope.
+
Exploit symmetry.
+
Design with components.
+
Build prototypes.
+
Make tradeoffs when you have to.
+
Keep it simple.
+
Strive for elegance.
+
-
-Epilog to the Second Edition of
-
-
-
Programming Pearls
+
+Epilog to the Second Edition of
+
+
+
Programming Pearls
-
-Errata for
-
-
-
Programming Pearls,
-
Second Edition
-
-
-unsigned int hash(char *p)
-
+
+Errata for
+
+
+
Programming Pearls,
+
Second Edition
+
+
+unsigned int hash(char *p)
+
-
-About the First Edition of
-
-
-
Programming Pearls
ISBN 0-201-10331-1.
-
195 + viii pp.
-
-
-Translations
-
-
-
-
-Web Reviews
-
-The Secret of
-Bill's
-Success?
-
+
+About the First Edition of
+
+
+
Programming Pearls
ISBN 0-201-10331-1.
+
195 + viii pp.
+
+
+Translations
+
+
+
+
+Web Reviews
+
+The Secret of
+Bill's
+Success?
+
-
-First-Year Instruction
-
-
-
in
-Programming Pearls
-
Engineering
-
Tricks of the Trade
-
Eyes Open to the World
-
Beauty
-
Elegance
-
Communication
-
Truth
-
History
-
Ethics
-
-Several of these topics are covered in the book.
-
-Tricks of the Trade
-Elegance
-History
-
+
+First-Year Instruction
+
+
+
in
+Programming Pearls
+
Engineering
+
Tricks of the Trade
+
Eyes Open to the World
+
Beauty
+
Elegance
+
Communication
+
Truth
+
History
+
Ethics
+
+Several of these topics are covered in the book.
+
+Tricks of the Trade
+Elegance
+History
+
-
-Programming Pearls,
-
-by Jon Bentley.
-
-
Second Edition
ISBN 0-201-65788-0.
-
239 + xi pp. $24.95
-![[new]](newicon.gif)
-What's new on this web site?
-
-
Table of Contents
-
Preface
-
Part I: Preliminaries
-
Column 1: Cracking the Oyster
-
Column 2: Aha! Algorithms [Sketch]
-
Column 4: Writing Correct Programs [Sketch]
-
Column 5: A Small Matter of Programming [Sketch]
-
Part II: Performance
-
Column 7: The Back of the Envelope
-
Column 8: Algorithm Design Techniques [Sketch]
-
Part III: The Product
-
Column 14: Heaps [Sketch]
-
Column 15: Strings of Pearls
-
Epilog to the First Edition
-
Epilog to the Second Edition
-
Appendix 2: An Estimation Quiz
-
Appendix 3: Cost Models for Time and Space
-
Appendix 4: Rules for Code Tuning
-
Solutions for
- Column 1
- Column 5
- Column 7
- Column 15
-
Index
-
-
Why a Second Edition?
-
To Readers of the First Edition
-
About the First Edition
-
Errata
-
-
Source Code
-
Web Sites Relevant to the Book
-
Animation of Sorting Algorithms
-
Tricks of the Trade
-
Teaching Material
-
-
-
-
-
-
-
-
-
+
+Programming Pearls,
+
+by Jon Bentley.
+
+
Second Edition
ISBN 0-201-65788-0.
+
239 + xi pp. $24.95
+
+What's new on this web site?
+
+
Table of Contents
+
Preface
+
Part I: Preliminaries
+
Column 1: Cracking the Oyster
+
Column 2: Aha! Algorithms [Sketch]
+
Column 4: Writing Correct Programs [Sketch]
+
Column 5: A Small Matter of Programming [Sketch]
+
Part II: Performance
+
Column 7: The Back of the Envelope
+
Column 8: Algorithm Design Techniques [Sketch]
+
Part III: The Product
+
Column 14: Heaps [Sketch]
+
Column 15: Strings of Pearls
+
Epilog to the First Edition
+
Epilog to the Second Edition
+
Appendix 2: An Estimation Quiz
+
Appendix 3: Cost Models for Time and Space
+
Appendix 4: Rules for Code Tuning
+
Solutions for
+ Column 1
+ Column 5
+ Column 7
+ Column 15
+
Index
+
+
Why a Second Edition?
+
To Readers of the First Edition
+
About the First Edition
+
Errata
+
+
Source Code
+
Web Sites Relevant to the Book
+
Animation of Sorting Algorithms
+
Tricks of the Trade
+
Teaching Material
+
+
+
+
+
+
+
+
+
-
-Long Repeated Strings
-
-
-
(Illustrating Section 15.2 of
-
Programming Pearls)
-
-King James Bible
-
-
-Verse Numbers Included
-the house of his precious things, the silver, and the gold, and the spices, and
-the precious ointment, and all the house of his armour, and all that was found
-in his treasures: there was nothing in his house, nor in all his dominion, that
-Hezekiah shewed them not.
-
-Verse Numbers Excluded
-, offered:
-His offering was one silver charger, the weight whereof was an hundred and thirty
-shekels, one silver bowl of seventy shekels, after the shekel of the sanctuary;
-both of them full of fine flour mingled with oil for a meat offering:
-One golden spoon of ten shekels, full of incense:
-One young bullock, one ram, one lamb of the first year, for a burnt offering:
-One kid of the goats for a sin offering:
-And for a sacrifice of peace offerings, two oxen, five rams, five he goats, five
-lambs of the first year: this was the offering of Ahi
-
-Longest String That Occurs Twelve Times
-, full of incense:
-One young bullock, one ram, one lamb of the first year, for a burnt offering:
-One kid of the goats for a sin offering:
-And for a sacrifice of peace offerings, two oxen, five rams, five he goats, five
- lambs of the first year: this was the offering of
-
-
-Programming Pearls
-
-
-The Entire Text
- 6, 8, 12, 17-18, 51-55, 59, 62, 70-72, 82, 87-98, 116, 119, 121,
-128, 137, 162, 164, 187-189, 206, 210, 214, 221, 230
-
-Index Excluded
-expression is costly,
-replace it by an algebraically equivalent expression
-that is cheaper to evaluate.
-I
-
-
-The Iliad
-
-
-The Entire Text
-whose sake so many of the Achaeans have
-died at Troy, far from their homes?
-Go about at once among the host,
-and speak fairly to them, man by man,
-that they draw not their ships into the sea.
-
-
-
+
+Long Repeated Strings
+
+
+
(Illustrating Section 15.2 of
+
Programming Pearls)
+
+King James Bible
+
+
+Verse Numbers Included
+the house of his precious things, the silver, and the gold, and the spices, and
+the precious ointment, and all the house of his armour, and all that was found
+in his treasures: there was nothing in his house, nor in all his dominion, that
+Hezekiah shewed them not.
+
+Verse Numbers Excluded
+, offered:
+His offering was one silver charger, the weight whereof was an hundred and thirty
+shekels, one silver bowl of seventy shekels, after the shekel of the sanctuary;
+both of them full of fine flour mingled with oil for a meat offering:
+One golden spoon of ten shekels, full of incense:
+One young bullock, one ram, one lamb of the first year, for a burnt offering:
+One kid of the goats for a sin offering:
+And for a sacrifice of peace offerings, two oxen, five rams, five he goats, five
+lambs of the first year: this was the offering of Ahi
+
+Longest String That Occurs Twelve Times
+, full of incense:
+One young bullock, one ram, one lamb of the first year, for a burnt offering:
+One kid of the goats for a sin offering:
+And for a sacrifice of peace offerings, two oxen, five rams, five he goats, five
+ lambs of the first year: this was the offering of
+
+
+Programming Pearls
+
+
+The Entire Text
+ 6, 8, 12, 17-18, 51-55, 59, 62, 70-72, 82, 87-98, 116, 119, 121,
+128, 137, 162, 164, 187-189, 206, 210, 214, 221, 230
+
+Index Excluded
+expression is costly,
+replace it by an algebraically equivalent expression
+that is cheaper to evaluate.
+I
+
+
+The Iliad
+
+
+The Entire Text
+whose sake so many of the Achaeans have
+died at Troy, far from their homes?
+Go about at once among the host,
+and speak fairly to them, man by man,
+that they draw not their ships into the sea.
+
+
+
-
-Letter-Level Markov Text
-
-
-
(Illustrating Section 15.3 of
-
Programming Pearls)
-
-The Book of Romans (King James Version)
-
-
-
-King James Bible (Complete Text)
-
-
-
-Column 10 of Programming Pearls
-
-
-
-Programming Pearls (Complete Text)
-
-
-
+
+Letter-Level Markov Text
+
+
+
(Illustrating Section 15.3 of
+
Programming Pearls)
+
+The Book of Romans (King James Version)
+
+
+
+King James Bible (Complete Text)
+
+
+
+Column 10 of Programming Pearls
+
+
+
+Programming Pearls (Complete Text)
+
+
+
-
-Word-Level Markov Text
-
-
-
(Illustrating Section 15.3 of
-
Programming Pearls)
-
-Source: King James Bible
-
-
-
-Source: Programming Pearls, Second Edition
-
-
-
+
+Word-Level Markov Text
+
+
+
(Illustrating Section 15.3 of
+
Programming Pearls)
+
+Source: King James Bible
+
+
+
+Source: Programming Pearls, Second Edition
+
+
+
-
-Preliminaries
-
-
-
(Part I of
-
Programming Pearls)
-
+
+Preliminaries
+
+
+
(Part I of
+
Programming Pearls)
+
-
-Performance
-
-
-
(Part II of
-
Programming Pearls)
-
-
-To wrap up Part II,
-Column 10 turns to another important aspect of performance:
-space efficiency.
-
-
-
+
+Performance
+
+
+
(Part II of
+
Programming Pearls)
+
+
+To wrap up Part II,
+Column 10 turns to another important aspect of performance:
+space efficiency.
+
+
+
-
-The Product
-
-
-
(Part III of
-
Programming Pearls)
-
+
+The Product
+
+
+
(Part III of
+
Programming Pearls)
+
-
-The Preface to
-
-
-
Programming PearlsAbout the Book
-
-The columns in this book are about a more glamorous
-aspect of the profession:
-programming pearls whose origins lie beyond solid engineering,
-in the realm of insight and creativity.
-Just as natural pearls grow from grains of sand
-that have irritated oysters,
-these programming pearls have grown from real
-problems that have irritated real programmers.
-The programs are fun,
-and they teach important programming techniques
-and fundamental design principles.
-
-The Code
-
-To Readers of the First Edition
-
-Acknowledgments for the First Edition
-
-Acknowledgments for the Second Edition
-
-
-
-
J. B.
-
Murray Hill, New Jersey
-
December, 1985
-
August, 1999
-
-
+
+The Preface to
+
+
+
Programming PearlsAbout the Book
+
+The columns in this book are about a more glamorous
+aspect of the profession:
+programming pearls whose origins lie beyond solid engineering,
+in the realm of insight and creativity.
+Just as natural pearls grow from grains of sand
+that have irritated oysters,
+these programming pearls have grown from real
+problems that have irritated real programmers.
+The programs are fun,
+and they teach important programming techniques
+and fundamental design principles.
+
+The Code
+
+To Readers of the First Edition
+
+Acknowledgments for the First Edition
+
+Acknowledgments for the Second Edition
+
+
+
+
J. B.
+
Murray Hill, New Jersey
+
December, 1985
+
August, 1999
+
+
-
-An Estimation Quiz
-
-
-
(Appendix 2 of
-
Programming Pearls)
-
+
+An Estimation Quiz
+
+
+
(Appendix 2 of
+
Programming Pearls)
+
-
-Precise Problem Statement
-
-
-
-To the programmer these requirements
-added up to,
-``How do I sort a disk file?''
-Before we attack the problem,
-let's arrange what we know in a less biased and more useful form.
-
(Section 1.2 of
-
Programming Pearls)
-
-
-
-
-Think for a minute about this problem specification.
-How would you advise the programmer now?
-
-
-
+
+Precise Problem Statement
+
+
+
+To the programmer these requirements
+added up to,
+``How do I sort a disk file?''
+Before we attack the problem,
+let's arrange what we know in a less biased and more useful form.
+
(Section 1.2 of
+
Programming Pearls)
+
+
+
+
+Think for a minute about this problem specification.
+How would you advise the programmer now?
+
+
+
-
-Program Design
-
-
-
(Section 1.3 of
-
Programming Pearls)
-
-
-
-The 40-pass algorithm reads the input file many times
-and writes the output just once,
-using no intermediate files.
-
-
-
-We would prefer the following scheme, which combines
-the advantages of the previous two.
-It reads the input just once,
-and uses no intermediate files.
-
-
-
-We can do this only if we represent all the integers
-in the input file in the available megabyte of main memory.
-Thus the problem boils down to whether we can
-represent at most ten million distinct integers in
-about
-eight million available bits.
-Think about an appropriate representation.
-
-
-
+
+Program Design
+
+
+
(Section 1.3 of
+
Programming Pearls)
+
+
+
+The 40-pass algorithm reads the input file many times
+and writes the output just once,
+using no intermediate files.
+
+
+
+We would prefer the following scheme, which combines
+the advantages of the previous two.
+It reads the input just once,
+and uses no intermediate files.
+
+
+
+We can do this only if we represent all the integers
+in the input file in the available megabyte of main memory.
+Thus the problem boils down to whether we can
+represent at most ten million distinct integers in
+about
+eight million available bits.
+Think about an appropriate representation.
+
+
+
-
-Implementation Sketch
-
-
-
(Section 1.4 of
-
Programming Pearls)
-
-The bits representing numbers in the set are 1,
-and all other bits are 0.
-
-
-0 1 1 1 0 1 0 0 1 0 0 0 0 1 0 0 0 0 0 0
-
-(Recall from the
-preface
-that the notation
-for i = [0, n)
-iterates i from 0 to n-1.)
-
-
-/* phase 1: initialize set to empty */
- for i = [0, n)
- bit[i] = 0
-/* phase 2: insert present elements into the set */
- for each i in the input file
- bit[i] = 1
-/* phase 3: write sorted output */
- for i = [0, n)
- if bit[i] == 1
- write i on the output file
-
+
+Implementation Sketch
+
+
+
(Section 1.4 of
+
Programming Pearls)
+
+The bits representing numbers in the set are 1,
+and all other bits are 0.
+
+
+0 1 1 1 0 1 0 0 1 0 0 0 0 1 0 0 0 0 0 0
+
+(Recall from the
+preface
+that the notation
+for i = [0, n)
+iterates i from 0 to n-1.)
+
+
+/* phase 1: initialize set to empty */
+ for i = [0, n)
+ bit[i] = 0
+/* phase 2: insert present elements into the set */
+ for each i in the input file
+ bit[i] = 1
+/* phase 3: write sorted output */
+ for i = [0, n)
+ if bit[i] == 1
+ write i on the output file
+
-
-Principles
-
-
-
(Section 1.5 of
-
Programming Pearls)
-
+
+Principles
+
+
+
(Section 1.5 of
+
Programming Pearls)
+
-
-Problems
-
-
-
-
(Section 1.6 of
-
Programming Pearls)
-
+
+Problems
+
+
+
+
(Section 1.6 of
+
Programming Pearls)
+
-
-Further Reading
-
-
-
-
(Section 1.7 of
-
Programming Pearls)
-
+
+Further Reading
+
+
+
+
(Section 1.7 of
+
Programming Pearls)
+
-
-Debugging
-
-
-
(Section 5.10 of
-
Programming Pearls)
-
+
+Debugging
+
+
+
(Section 5.10 of
+
Programming Pearls)
+
-
-
-Basic Skills
-
-
-
(Section 7.1 of
-
Programming Pearls)
-
-1000 miles * 1000 miles * 1/5000 mile/year
- ~
-200 miles3/year
-
-(200 miles3/year) / (400 days/year)
- ~
-1/2 mile3/day
-
-
-or a little more than half a cubic mile per day.
-It's important to double check all calculations,
-and especially so for quick ones.
-
-
-
-640,000ft3/sec * 3600 secs/hr
- ~
-2.3x109ft3 / hr
-
-
-2.3x109ft3/hr * 24hrs/day
- ~
-6x1010ft3/day
-
-
-6x1010ft3/day / (5000ft/mile)3
-
-
- ~
-6x1010ft3/day /
-(125x109ft3/mile3)
-
-
- ~
-60/125 mile3/day
-
-
- ~
-1/2 mile3/day
-
-
-The proximity of the two estimates to one another,
-and especially to the almanac's answer,
-is a fine example of sheer dumb luck.
-
-
-
-(miles + miles) x miles x miles / day
- ~
-miles3/day
-
-
-has the right form, apart from any constants.
-
-
-
-
-Next we simplify the expression by cancelling terms,
-which shows that the output is 200 miles3/year.
-
-
-
-Now we multiply by the identity (well, almost)
-that there are 400 days per year.
-
-
-
-Cancellation yields the (by now familiar)
-answer of half a cubic mile per day.
-
-
-
-These tabular calculations help you keep track of dimensions.
-
-
-
-The first sum has too few digits and the second sum errs
-in the least significant digit.
-The technique of ``casting out nines''
-reveals the error in the third example:
-the digits in the summands sum to 8 modulo 9,
-while those in the answer sum to 7 modulo 9.
-In a correct addition, the sums of the digits
-are equal after ``casting out'' groups of digits
-that sum to nine.
-
-
- 3142 3142 3142
- 2718 2718 2718
-+1123 +1123 +1123
- 983 6982 6973
-
-Pi seconds is a nanocentury.
-
-Because the exponential program takes 107 seconds,
-we should be prepared to wait about four months.
-
-
+
+
+Basic Skills
+
+
+
(Section 7.1 of
+
Programming Pearls)
+
+1000 miles * 1000 miles * 1/5000 mile/year
+ ~
+200 miles3/year
+
+(200 miles3/year) / (400 days/year)
+ ~
+1/2 mile3/day
+
+
+or a little more than half a cubic mile per day.
+It's important to double check all calculations,
+and especially so for quick ones.
+
+
+
+640,000ft3/sec * 3600 secs/hr
+ ~
+2.3x109ft3 / hr
+
+
+2.3x109ft3/hr * 24hrs/day
+ ~
+6x1010ft3/day
+
+
+6x1010ft3/day / (5000ft/mile)3
+
+
+ ~
+6x1010ft3/day /
+(125x109ft3/mile3)
+
+
+ ~
+60/125 mile3/day
+
+
+ ~
+1/2 mile3/day
+
+
+The proximity of the two estimates to one another,
+and especially to the almanac's answer,
+is a fine example of sheer dumb luck.
+
+
+
+(miles + miles) x miles x miles / day
+ ~
+miles3/day
+
+
+has the right form, apart from any constants.
+
+
+
+
+Next we simplify the expression by cancelling terms,
+which shows that the output is 200 miles3/year.
+
+
+
+Now we multiply by the identity (well, almost)
+that there are 400 days per year.
+
+
+
+Cancellation yields the (by now familiar)
+answer of half a cubic mile per day.
+
+
+
+These tabular calculations help you keep track of dimensions.
+
+
+
+The first sum has too few digits and the second sum errs
+in the least significant digit.
+The technique of ``casting out nines''
+reveals the error in the third example:
+the digits in the summands sum to 8 modulo 9,
+while those in the answer sum to 7 modulo 9.
+In a correct addition, the sums of the digits
+are equal after ``casting out'' groups of digits
+that sum to nine.
+
+
+ 3142 3142 3142
+ 2718 2718 2718
++1123 +1123 +1123
+ 983 6982 6973
+
+Pi seconds is a nanocentury.
+
+Because the exponential program takes 107 seconds,
+we should be prepared to wait about four months.
+
+
-
-Performance Estimates
-
-
-
(Section 7.2 of
-
Programming Pearls)
-
-Back-of-the-envelope quiz:
-will two million such nodes fit in the main memory
-of your 128-megabyte computer?
-
-
-struct node { int i; struct node *p; };
-
-My system represented each record in eight bytes,
-as I expected.
-The 16 megabytes should fit comfortably into the
-85 megabytes of free memory.
-
-
-printf("sizeof(struct node)=%d\n", sizeof(struct node));
-
-I expected precisely those values from my 32-bit compiler.
-Further experiments measured the differences between
-successive pointers returned by the storage allocator;
-this is a plausible guess at record size.
-(One should always verify such rough guesses with other tools.)
-I now understand that,
-with this space-hogging allocator,
-records between 1 and 12 bytes will consume 48 bytes of memory,
-records between 13 and 28 bytes will consume 64 bytes,
-and so forth.
-We will return to this space model in Columns 10 and 13.
-
-
-sizeof(char)=1 sizeof(short)=2 sizeof(int)=4
-sizeof(float)=4 sizeof(struct *)=4 sizeof(long)=4
-sizeof(double)=8
-
-I ran the program with a command to report how much
-time it takes
-(I check such times with an old digital watch
-that I keep next to my computer;
-it has a broken band but a working stopwatch).
-I found that the program took
-about 0.2 seconds to computer one million square roots,
-2 seconds to compute ten million,
-and 20 seconds to compute 100 million.
-I would guess that it will take
-about 200 seconds to compute a billion square roots.
-
-
-#include
+
+Performance Estimates
+
+
+
(Section 7.2 of
+
Programming Pearls)
+
+Back-of-the-envelope quiz:
+will two million such nodes fit in the main memory
+of your 128-megabyte computer?
+
+
+struct node { int i; struct node *p; };
+
+My system represented each record in eight bytes,
+as I expected.
+The 16 megabytes should fit comfortably into the
+85 megabytes of free memory.
+
+
+printf("sizeof(struct node)=%d\n", sizeof(struct node));
+
+I expected precisely those values from my 32-bit compiler.
+Further experiments measured the differences between
+successive pointers returned by the storage allocator;
+this is a plausible guess at record size.
+(One should always verify such rough guesses with other tools.)
+I now understand that,
+with this space-hogging allocator,
+records between 1 and 12 bytes will consume 48 bytes of memory,
+records between 13 and 28 bytes will consume 64 bytes,
+and so forth.
+We will return to this space model in Columns 10 and 13.
+
+
+sizeof(char)=1 sizeof(short)=2 sizeof(int)=4
+sizeof(float)=4 sizeof(struct *)=4 sizeof(long)=4
+sizeof(double)=8
+
+I ran the program with a command to report how much
+time it takes
+(I check such times with an old digital watch
+that I keep next to my computer;
+it has a broken band but a working stopwatch).
+I found that the program took
+about 0.2 seconds to computer one million square roots,
+2 seconds to compute ten million,
+and 20 seconds to compute 100 million.
+I would guess that it will take
+about 200 seconds to compute a billion square roots.
+
+
+#include
-
-Safety Factors
-
-
-
(Section 7.3 of
-
Programming Pearls)
-
+
+Safety Factors
+
+
+
(Section 7.3 of
+
Programming Pearls)
+
-
-Little's Law
-
-
-
(Section 7.4 of
-
Programming Pearls)
-
+
+Little's Law
+
+
+
(Section 7.4 of
+
Programming Pearls)
+
-
-Principles
-
-
-
(Section 7.5 of
-
Programming Pearls)
-
-We know that simple calculations aren't too simple
-by including safety factors to compensate for our
-mistakes in estimating parameters and our ignorance of
-the problem at hand.
-
-
-
+
+Principles
+
+
+
(Section 7.5 of
+
Programming Pearls)
+
+We know that simple calculations aren't too simple
+by including safety factors to compensate for our
+mistakes in estimating parameters and our ignorance of
+the problem at hand.
+
+
+
-
-Problems
-
-
-
(Section 7.6 of
-
Programming Pearls)
-
-
-
-
+
+Problems
+
+
+
(Section 7.6 of
+
Programming Pearls)
+
+
+
+
-
-Further Reading
-
-
-
-
(Section 7.7 of
-
Programming Pearls)
-
-A number of relevant web pages can be found by searching
-for strings like ``back of the envelope''
-and ``Fermi problems''.
-
-
-
+
+Further Reading
+
+
+
+
(Section 7.7 of
+
Programming Pearls)
+
+A number of relevant web pages can be found by searching
+for strings like ``back of the envelope''
+and ``Fermi problems''.
+
+
+