1321

1. 1321 CS

2. CS1321:Introduction to Programming Georgia Institute of Technology College of Computing Lecture 14 October 9, 2001 Fall Semester

3. Today’s Menu • Refining your Design • Processing Multiple Lists at the same time

4. Refining your plans… One of the biggest pitfalls you’ll face in Computer Science (and indeed, your life) is assuming your plans are perfect from the get-go. Oftentimes you’ll come up with a plan or a design, put it down on paper (or type it up on your computer), jump through all the hoops, spend all night (or several weeks) programming it up, only to discover that you forgot that one tiny little important detail that…well…makes everything work.

5. Taking the Step Back… Sometimes it’s necessary to step back from our design and seriously re-examine and refine the thought process that went into it. We might spot the flaws in our logic that escaped us in the initial rush of enthusiasm. We might have to redo part or all of our design. We might have to do this multiple times… The book labels this thought process ITERATIVE REFINEMENT.

6. Iterative Refinement: An example. Your instructor has given you the following task: Model a directory structure. That’s it. Everything else is left to your imagination. So let’s look at what we’re modeling…

7. What’s shown here is a directory structure. You’ll note that a directory consists of files and other directories.

8. At first blush… Our first thought process might be along the lines of the following: 1. A file is basically a symbol (its name) 2. A directory can contain many files or other directories (hey, that’s a list!)

9. So… A file is a symbol. A directory is either: 1) the empty list, empty 2) (cons f d) where f is a file and d is a directory 3) (cons d1 d2) where d1 and d2 are directories But wait a minute… Don’t directories have names? And other attributes? Hmmm…maybe we should re-think this…

10. Take two… Let’s just say that directories have names… A directory is a structure: (make-dir n c) Where n is a symbol and c is a list-of-files-and-dirs A list-of-files-and-dirs (or LOFD for short) is either: 1) empty 2) (cons f d) where f is a file and d is a LOFD 3) (cons d1 d2) where d1 is a directory and d2 is a LOFD

11. Oh wait… Did we forget to mention that files have properties too? Such as a name, a date created, and a type? And doesn’t it seem awful silly to have just one list to store both files and directories? Let’s put our thinking caps on one more time…

12. One more time through… A file is a structure: (make-file n d x) Where n is a symbol, d is a number, and x is some Scheme value. A list-of-files (LOF) is either: 1) empty 2) (cons f lof) where f is a file and lof is a LOF

13. Furthermore… A directory is a structure (make-dir n lod lof) Where n is a symbol, lod is a list-of-directories and lof is a list-of-files. A list-of-directories is either 1) empty 2) (cons d lod) where d is a directory and lod is a list-of-directories.

14. Working with directories in Scheme… The exercises in chapter 16 ask you to work with directories within the DrScheme environment. To make your life easier, you should load in the dir.ss teachpack in the htdp directory. This teachpack gives you a data definition for directories and files, as well as a function to create directories. See your Help Desk for details.

15. Processing Multiple Pieces of Complex Data: Establishing Patterns. Over the course of the past few weeks, we’ve examined in great detail the problem of processing single pieces of complex data within a function. For example, if we were asked to create a function that consumes a list-of-number definition and sums all the numbers with that list, we could immediately begin by starting with a generic template for working with our list…

16. (define (process-lon lon1) (cond ((empty? lon1) …) (else …(first lon1) …(process-lon (rest lon1)))))

17. (define (process-lon lon1) (cond ((empty? lon1) …) (else …(first lon1) …(process-lon (rest lon1))))) To our final function…. (define (summation lon1) (cond ((empty? lon1) 0) (else (+ (first lon1) (summation (rest lon1))))))

18. We’ve also recently examined working with more complex data definitions that allow for “branching” within the data, such as a nested list of numbers. Again, we’ve looked at going from our template… (define (process-nlon nlon1) (cond ((empty? nlon1) 0) ((list? (first nlon1)) …(process-nlon (first nlon1)) …(process-nlon (rest nlon1))) (else …(first nlon1) …(process-nlon (rest nlon1)))))

19. To a function which processes them, such as flatten: (define (flatten nlon1) (cond ((empty? nlon1) empty) ((list? (first nlon1)) (append (flatten (first nlon1)) (flatten (rest nlon1)))) (else (append (list (first nlon1)) (flatten (rest nlon1))))))

20. Or we could even use cons in this case: (define (flatten nlon1) (cond ((empty? nlon1) empty) ((list? (first nlon1)) (append (flatten (first nlon1)) (flatten (rest nlon1)))) (else (cons (first nlon1)) (flatten (rest nlon1)))))

21. But what about… One thing that we haven’t examined in great detail is dealing with multiple pieces of those complex data types at the same time… When dealing with multiple pieces of data at the same time, it’s important to recognize how we’re dealing with those pieces of data. In the following slides, we’ll try to establish some patterns of how we deal with multiple lists…

22. One List as Baggage: Append For this example, we’ll be examining a function introduced in the last lecture: append. Append is a very tempting function. Seemingly more powerful than a simple cons call, append gives us the ability to merge multiple lists into one list using a single function call. Let’s examine the behavior of append one more time:

23. Working with Append

24. The Inner-workings of Append In previous lectures, we labeled lists as dynamic data types. Dynamic Data Types grow and shrink to accommodate the amount of data that need to be stored. We add and remove elements to and from our dynamic data type as needed. So how can we simply add one list to the last cons cell of a list whose length we don’t know?

25. We don’t… The simple answer is that we do not “just add a list” to the end of another list. The function hides (abstracts) what it’s really doing from the user. Judging from the example shown previously, let’s try establish some rules: If both lists are empty, return the empty list If the first list is empty, return the second. If the second list is empty, return the first. If neither lists are empty, replace the empty at the end of the first list with a link to the second.

26. These conditions are the same Reducing what we have to work with… If both lists are empty, return the empty list If the first list is empty, return the second. If the second list is empty, return the first. These conditions are the same If neither lists are empty, replace the empty at the end of the first list with a link to the second.

27. Reducing what we have to work with… If the first list is empty, return the second. If neither lists are empty, replace the empty at the end of the first list with a link to the second.

28. If the first list is empty, return the second. If neither lists are empty, replace the empty at the end of the first list with a link to the second. The important question… Do we have to do anything with the second list besides add it to the end of the first? NO

29. So… What we have is a case where we are essentially ignoring the fact that our second piece of data is a complex data definition. Our first piece of data drives the entire function: (define (process-two-lists-1 nlon1 nlon2) (cond ((empty? nlon1) …) (else …(first nlon1) …(process-two-lists-1 (rest nlon1) nlon2))))

30. (define (my-append nlon1 nlon2) (cond ((empty? nlon1) nlon2) (else (cons (first nlon1) (my-append (rest nlon1) nlon2))))

31. Both Lists in Lockstep: Revenue The case where our second piece of data doesn’t really come into the mix won’t be the case in every problem. Let’s examine a more complex case:

32. Your boss has asked you to return to the problem of TA salary. Recently he discovered some older data dating back to 1985. Back in those days, the financial services department didn’t use any fancy features like structures to organize information about a single TA into one cohesive unit. They relied on positional information to join together information like TA salary and TA hours. In other words, they used multiple lists of EXACTLY equal size to store information about TAs. The fifth entry in the salary list would be the salary for the fifth entry in the name list.

33. Your job is to take some of these old lists representing pay and hours and calculate the amount gross pay of each TA from the year 1985. You should return a list… You’ll note that in this case, we have to process each list (not just the first list or the second list), but we’ve been guaranteed that the two lists will be exactly the same size. Pictorially…

34. 31 empty 40 9 Hours worked 31 empty 20 18 Salary empty 2 1 0.50 Pay

35. Let’s see what this does to our template… (define (process-two-lists-2 in-nlon1 in-nlon2) (cond ((empty? in-nlon1) …) (else …(first in-nlon1) …(first in-nlon2) …(process-two-lists-2 (rest in-nlon1) (rest in-nlon2)))))

36. Let’s see what this does to our template… (define (process-two-lists-2 in-nlon1 in-nlon2) (cond ((empty? in-nlon1) …) (else …(first in-nlon1) …(first in-nlon2) …(process-two-lists-2 (rest in-nlon1) (rest in-nlon2))))) We are dealing with both lists, so we process both lists simultaneously

37. Translating into code… (define (revenue in-nlon1 in-nlon2) (cond ((empty? in-nlon1) empty) (else (cons (* (first in-nlon1) (first in-nlon2)) (revenue (rest in-nlon1) (rest in-nlon2)))))

38. So what about…? One of the things we haven’t shown here has been working with two lists simultaneously. “But hasn’t this whole lecture been about just that?”

39. Actually… It really hasn’t been about processing lists simultaneously. So far we’ve dealt with lists by themselves, multiple lists where one list doesn’t really matter, and lists that are guaranteed to be the same length. What about lists of different lengths? Or problems where we’d want to work with each list, but conditionally?

40. Setting up for next time… Let’s consider a new problem. A few lectures ago, we spent a lot of time building a set of functions to act out a particular sorting function: insertion sort. Now, Insertion Sort isn’t the only sorting algorithm available to us as programmers. We’ve come up with a great many over the years. One particular sort that we’d like to look at (in part) is merge sort.

41. The basic gist of things Merge sort is what’s called a “divide and conquer” algorithm. It consumes as input a “list” of items, hacks the list apart as small as it can, and then re-assembles the lists by merging them together. Or more simply:

42. We go from this Back to this… Remember the T-1000?

43. Of course… That kind of explanation leaves out a lot of the details. Merge sort is actually a fairly complex problem. For right now, we’ll only be interested in the “merging” aspect of the algorithm. But we’ll cover that next time…