1 / 18

Algorithms, Part 3 of 3

Algorithms, Part 3 of 3. Topics Top down-design Reading Sections 1.4 – 1.5 , 3.3. Pseudocode and Then Some. We can write an algorithm for finding the average of two integers: Read integer <num1>, from the user Read integer <num2> from the user <sum> = <num1> + <num2>

waggonerd
Download Presentation

Algorithms, Part 3 of 3

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Algorithms, Part 3 of 3 Topics • Top down-design Reading • Sections 1.4 – 1.5 , 3.3

  2. Pseudocode and Then Some • We can write an algorithm for finding the average of two integers: Read integer <num1>, from the user Read integer <num2> from the user <sum> = <num1> + <num2> <average> = <sum> / 2 Display “The average of <num1> “and” <num2 > “is” <average>. • Steps 1, 2 & 5 will make use of code found in the run-time library. 1 2 3 4 5

  3. Investigating Steps 1 & 5 Read integer <num1>, from the user Display “The average =” <average>. • Are these really single steps? • Each of them is really a sequence of steps, a subprogram. Two kinds of subprograms: • Functions - an answer is returned to the main program. • Procedures - no answer returned to the main program

  4. Functions and Procedures • In our example, the function that gets a value from the user and the procedure that prints out the answer were already written. • Many times it is necessary for us to write our own procedures or functions.

  5. Top-Down Design • If we look at a problem as a whole, it may seem impossible to solve because it is so complex. Examples: • writing a tax computation program • writing a word processor • Complex problems can be solved using top-down design, also known as stepwise refinement. • We break the problem into parts • Then break the parts into parts • Soon, each of the parts will be easy to do

  6. Advantages of Top-Down Design • Breaking the problem into parts helps us to clarify what needs to be done. • At each step of refinement, the new parts become less complicated and, therefore, easier to figure out. • Parts of the solution may turn out to be reusable. • Breaking the problem into parts allows more than one person to work on the solution.

  7. An Example of Top-Down Design • Scenario: • We own a home improvement company. • We do painting, roofing, and basement waterproofing. • A section of town has recently flooded (zip code 21222). • We want to send out pamphlets to our customers in that area.

  8. The Top Level • Get the customer list from a file. • Sort the list according to zip code. • Make a new file of only the customers with the zip code 21222 from the sorted customer list. • Print an envelope for each of these customers. Main Read Sort Select Print

  9. Pseudocode for our Main Program • Start • Call Read Customer List • Call Sort on customer list by zipcode • Call Select Target List from Customer List using only zipcode 21222 • Call Print Envelopes using target list • Stop

  10. Another Level? • Should any of these steps be broken down further? Possibly. • How do I know? Ask yourself whether or not you could easily write the algorithm for the step. If not, break it down again. • When you are comfortable with the breakdown, write pseudocode for each of the steps (modules) in the hierarchy.

  11. Structured Programs • We will use top-down design for all of our programming projects. • This is the standard way of writing programs. • Programs produced using this method and using only the three kinds of control structures, sequential, selection and repetition, are called structured programs. • Structured programs are easier to test, modify, and are also easier for other programmers to understand.

  12. Another Example • Problem: Write a program that draws this picture of a house.

  13. The Top Level • Draw the outline of the house • Draw the chimney • Draw the door • Draw the windows Main Draw Outline Draw Chimney Draw Door Draw Windows

  14. Observation • The door has both a frame and knob. We could break this into two steps. Main Draw Outline Draw Chimney Draw Door Draw Windows Draw Door Frame Draw Knob

  15. Another Observation • There are three windows to be drawn. Main Draw Outline Draw Windows . . . Draw Window 1 Draw Window 2 Draw Window 3 (x1,y1) (x2,y2) (x3,y3)

  16. Code Reuse • But don’t the windows look the same? They just have different locations. • So, we can reuse the code that draws a window. • Simply copy the code three times and edit it to place the window in the correct location, or • Use the code three times, “sending it” the correct location each time (we will see how to do this later). • This is an example of code reuse.

  17. The Pseudocode • Start • Call DrawHouseOutline giving a position • Call DrawChimney giving position • Call DrawDoor giving position • Call DrawWindow giving (x,y) position #1 • Call DrawWindow giving (x,y) position #2 • Call DrawWindow giving (x,y) position #3 • Stop

  18. Summary • Use the divide-and conquer strategy to split the original problem into a series of sub-problems. • Consider each sub-problem separately and split them further into smaller sub-problems, progressively refining the previous versions in a top-to-bottom manner, until no further refinement is possible. Stop the process when you have the pseudocode that can be directly translated in a C program.

More Related