CS 1321. CS1321: Introduction to Programming Georgia Institute of Technology College of Computing Lecture 13 October 4, 2001 Fall Semester.

Slides:



Advertisements
Similar presentations
Chapter 13. Red-Black Trees
Advertisements

Higher-Order Functions and Loops c. Kathi Fisler,
PRESENTED BY MATTHEW GRAF AND LEE MIROWITZ Linked Lists.
S3 Useful Expressions.
CS 206 Introduction to Computer Science II 09 / 24 / 2008 Instructor: Michael Eckmann.
Recursive Data 2 Mutually Recursive Data Definitions (HTDP sec 15.1)
Multi-way Trees CS 5010 Program Design Paradigms “Bootcamp” Lesson 6.6 © Mitchell Wand, This work is licensed under a Creative Commons Attribution-NonCommercial.
Developing Programs for Family Trees c. Kathi Fisler, 2001.
Developing Programs for Family Trees c. Kathi Fisler, 2001.
Lisp. Versions of LISP Lisp is an old language with many variants –LISP is an acronym for List Processing language Lisp is alive and well today Most modern.
CS 206 Introduction to Computer Science II 10 / 01 / 2008 Instructor: Michael Eckmann.
CS 206 Introduction to Computer Science II 09 / 22 / 2008 Instructor: Michael Eckmann.
CS 206 Introduction to Computer Science II 02 / 11 / 2009 Instructor: Michael Eckmann.
CSC 160 Computer Programming for Non-Majors Lecture #7: Variables Revisited Prof. Adam M. Wittenstein
CS 106 Introduction to Computer Science I 10 / 15 / 2007 Instructor: Michael Eckmann.
CS 106 Introduction to Computer Science I 10 / 16 / 2006 Instructor: Michael Eckmann.
Binary “There are 10 types of people in the world… those that understand binary and those that don’t.”
Simplifying Rational Expressions – Part I
Solving Your Problem by Generalization CS 5010 Program Design Paradigms “Bootcamp” Lesson 7.1 © Mitchell Wand, This work is licensed under a.
CS 206 Introduction to Computer Science II 09 / 30 / 2009 Instructor: Michael Eckmann.
CS CS1321: Introduction to Programming Georgia Institute of Technology College of Computing Lecture 5 Sept 4th, 2001 Fall Semester.
by Chris Brown under Prof. Susan Rodger Duke University June 2012
CS CS1321: Introduction to Programming Georgia Institute of Technology College of Computing Lecture 11 Sept 27th, 2001 Fall Semester.
Bill's Amazing Content Rotator jQuery Content Rotator.
Unit 2, cont. September 12 More HTML. Attributes Some tags are modifiable with attributes This changes the way a tag behaves Modifying a tag requires.
Priority Queues and Binary Heaps Chapter Trees Some animals are more equal than others A queue is a FIFO data structure the first element.
“The study of algorithms is the cornerstone of computer science.” Algorithms Fall 2011.
C++ crash course Class 8 statements, sort, flight times program.
CS 206 Introduction to Computer Science II 10 / 05 / 2009 Instructor: Michael Eckmann.
CS 206 Introduction to Computer Science II 02 / 13 / 2009 Instructor: Michael Eckmann.
CS CS1321: Introduction to Programming Georgia Institute of Technology College of Computing Lecture 27 November 29, 2001 Fall Semester.
CS CS1321: Introduction to Programming Georgia Institute of Technology College of Computing Lecture 10 Sept 25th, 2001 Fall Semester.
1 CS161 Introduction to Computer Science Topic #9.
Week 8 - Wednesday.  What did we talk about last time?  Level order traversal  BST delete  2-3 trees.
More examples of invariants CS 5010 Program Design Paradigms “Bootcamp” Lesson © Mitchell Wand, This work is licensed under a Creative.
Creating a Historical Tour in Alice By Jenna Hayes May 2010.
Solving Your Problem by Generalization CS 5010 Program Design Paradigms “Bootcamp” Lesson 7.1 © Mitchell Wand, This work is licensed under a.
Lists vs. Structures CS 5010 Program Design Paradigms “Bootcamp” Lesson © Mitchell Wand, This work is licensed under a Creative Commons.
Cs1321 December 6, 2001 Review. What is computer science? What's an algorithm? Processes and programs Overview of some programming language concepts Functional.
Week 10 - Friday.  What did we talk about last time?  Graph representations  Adjacency matrix  Adjacency lists  Depth first search.
Lecture on Set! And Local CS 2135 Copyright Kathi Fisler, 2002 This material requires Advanced Language Level.
CS CS1321: Introduction to Programming Georgia Institute of Technology College of Computing Lecture 6 Sept 6th, 2001 Fall Semester.
CSE 143 Lecture 13 Recursive Backtracking slides created by Ethan Apter
Sometimes Structural Recursion Isn't Enough CS 5010 Program Design Paradigms “Bootcamp” Lesson 8.1 TexPoint fonts used in EMF. Read the TexPoint manual.
BINARY TREES Objectives Define trees as data structures Define the terms associated with trees Discuss tree traversal algorithms Discuss a binary.
Searching CSE 103 Lecture 20 Wednesday, October 16, 2002 prepared by Doug Hogan.
BIT 115: Introduction To Programming Professor: Dr. Baba Kofi Weusijana (say Doc-tor Way-oo-see-jah-nah, Doc-tor, or Bah-bah)
Lecture 3: Rules of Evaluation CS150: Computer Science
INF3110 Group 2 EXAM 2013 SOLUTIONS AND HINTS. But first, an example of compile-time and run-time type checking Imagine we have the following code. What.
1 AVL Trees II Implementation. 2 AVL Tree ADT A binary search tree in which the balance factor of each node is 0, 1, of -1. Basic Operations Construction,
By: Megan Funk. I will: 1. Explain the binary number system How to: -Generate binary from a number -Add binary 2. Explain the base-b number system 3.
CMSC201 Computer Science I for Majors Lecture 19 – Recursion
User-Written Functions
CS 5010 Program Design Paradigms “Bootcamp” Lesson 5.2
Week 7 - Friday CS221.
More About Recursive Data Types
Loops BIS1523 – Lecture 10.
CMSC201 Computer Science I for Majors Lecture 18 – Recursion
CS 1321.
Halting Functions for Tree-Like Structures
B+ Trees What are B+ Trees used for What is a B Tree What is a B+ Tree
CMSC201 Computer Science I for Majors Lecture 16 – Recursion
CMSC201 Computer Science I for Majors Lecture 19 – Recursion
Heaps Chapter 11 has several programming projects, including a project that uses heaps. This presentation shows you what a heap is, and demonstrates.
Heaps Chapter 11 has several programming projects, including a project that uses heaps. This presentation shows you what a heap is, and demonstrates.
CS 5010 Program Design Paradigms “Bootcamp” Lesson 6.5
Recursion Taken from notes by Dr. Neil Moore
More examples of invariants
Developing Programs for Family Trees
Bringing it all Together: Family Trees
Presentation transcript:

CS 1321

CS1321: Introduction to Programming Georgia Institute of Technology College of Computing Lecture 13 October 4, 2001 Fall Semester

Today’s Menu 1.Lists in Lists: Applying the concept of trees to non-trees… 2. Cross-Referencing your structures.

Last time… We explored the concept of trees and types of trees in greater detail. de b f g c a We talked a little bit about how dealing with the data inside of trees was a more complex process than dealing with data in a “flat” data structure such as a list…

Why was that? In a list, we recur down a single path. We commonly deal with that by doing something similar to the following: ( + (first my-list) (recursive-call (rest my-list))) empty

Why was that? In a list, we recur down a single path. We commonly deal with that by doing something similar to the following: ( + (first my-list) (recursive-call (rest my-list))) empty We deal with each item in the list linearly, moving from one item to the next in our recursive call until we reach a terminating condition.

( + (node-data my-tree) (recursive-call (node-left my-tree)) (recursive-call (node-right my-tree))) But in trees… We don’t have that nice, linear structure to follow as we try to deal with our information. We have branches, and we have to follow those branches as the problem requires.

We gave this type of branching recursion a name… We called it tree recursion. After all, we were using it to manipulate values in a tree structure. You may have the impression that tree recursion was only for trees. But is that the case?

As it turns out… Tree recursion doesn’t just deal with trees. It’s very useful when dealing with our trees of varying shapes and sizes, from binary to n-ary trees… But we can also create other examples where this concept of joining together different branches of recursive calls is particularly useful. Such as…

List of Lists… ;; a nested-list-of-numbers is either: ;; 1) the empty list, empty, ;; 2) (cons n nlon) where n is a number and nlon is ;; nested-list-of-numbers, or ;; 3) (cons data-nlon nlon) where data-nlon and ;; nlon are both nested-list-of-numbers

Pictorially… e e e e For the sake of space “e” stands for empty e

Pictorially… e e e e Or using short-hand: ‘((3 (16) 8) 4 (4 7 12) 6 7)

What would this do to our template? Just as when we created our “shape” definition, we just add more conditions to the cond statement: (define (process-nlon my-nlon) (cond ((empty? my-nlon) …) ((list? (first my-nlon)) …(first my-nlon) …(process-nlon (rest my-nlon))) (else …(first my-nlon) …(process-nlon (rest my-nlon)))))

What would this do to our template? Just as when we created our “shape” definition, we just add more conditions to the cond statement: (define (process-nlon my-nlon) (cond ((empty? my-nlon) …) ((list? (first my-nlon)) …(first my-nlon) …(process-nlon (rest my-nlon))) (else …(first my-nlon) …(process-nlon (rest my-nlon))))) But wait….we didn’t do anything different if our first item was in fact a nested-list of numbers… Shouldn’t we process that first nested list?

Tree Recursion on lists… ((list? (first my-nlon)) …(process-nlon (first my-nlon)) …(process-nlon (rest my-nlon))) (else …(first my-nlon) …(process-nlon (rest my-nlon))))) Chances are, we do want to process the nested list. So we add another recursive call… See the two recursive calls even under one question of the cond? That is what makes this “tree recursion” (more than one recursive call so we handle both branches in this case.)

((list? (first my-nlon)) …(process-nlon (first my-nlon)) …(process-nlon (rest my-nlon))) What we are doing in this example is “branching” our recursion down the new path that we’ve found in our list. Much as we “branched” down each of the paths in our tree example… After all…

We could just “rotate” our nested list a little…

And it even looks like a tree!

So thinking through a problem… Your boss decides one day that he doesn’t like nested lists of numbers. He’d rather just deal with flat, one level list of numbers instead. Write a function called flatten that consumes a nested-list-of-numbers and returns a normal list-of- numbers (as we defined many times in the past few weeks).

Before we begin… We need to introduce a scheme function that will be absolutely essential to our flatten function: (append )  takes in a list 1 and a list 2 and appends (adds) all the items from the second list to the end of list 1. (append empty empty)  empty (append ‘(1 2 3) empty)  (list 1 2 3) (append empty ‘(4 5 6))  (list 4 5 6) (append ‘(1 2 3) ‘(4 5 6))  (list )

Append Note: In every case, append takes lists as parameters! (It cannot be used directly to add a number or a symbol for example to a list.) It is used to put two lists together forming one list. (append )  takes in a list 1 and a list 2 and appends (adds) all the items from the second list to the end of list 1. (append empty empty)  empty (append ‘(1 2 3) empty)  (list 1 2 3) (append empty ‘(4 5 6))  (list 4 5 6) (append ‘(1 2 3) ‘(4 5 6))  (list )

Let’s start with our template… (define (process-nlon my-nlon) (cond ((empty? my-nlon) …) ((list? (first my-nlon)) …(process-nlon (first my-nlon)) …(process-nlon (rest my-nlon))) (else …(first my-nlon) …(process-nlon (rest my-nlon)))))

Fill in the easy parts… (define (flatten my-nlon) (cond ((empty? my-nlon) empty) ((list? (first my-nlon)) …(flatten (first my-nlon)) …(flatten (rest my-nlon))) (else …(first my-nlon) …(flatten (rest my-nlon)))))

(define (flatten my-nlon) (cond ((empty? my-nlon) empty) ((list? (first my-nlon)) …(flatten (first my-nlon)) …(flatten (rest my-nlon))) (else …(first my-nlon) …(flatten (rest my-nlon))))) What do we want back from flatten? A flat list of numbers. In the cond under list? we have two calls to flatten. We produce two flat list of numbers; how do we join them into one list??

(define (flatten my-nlon) (cond ((empty? my-nlon) empty) ((list? (first my-nlon)) (append (flatten (first my-nlon)) (flatten (rest my-nlon)))) (else …(first my-nlon) …(flatten (rest my-nlon))))) We use append.

(define (flatten my-nlon) (cond ((empty? my-nlon) empty) ((list? (first my-nlon)) (append (flatten (first my-nlon)) (flatten (rest my-nlon)))) (else …(first my-nlon) …(flatten (rest my-nlon))))) Shouldn’t we do something similar for this case?

(define (flatten my-nlon) (cond ((empty? my-nlon) empty) ((list? (first my-nlon)) (append (flatten (first my-nlon)) (flatten (rest my-nlon)))) (else (append (first my-nlon) (flatten (rest my-nlon)))))) Shouldn’t we do something similar for this case? Is that okay?

(define (flatten my-nlon) (cond ((empty? my-nlon) empty) ((list? (first nlon)) (append (flatten (first nlon)) (flatten (rest my-nlon)))) (else (append (first nlon) (flatten (rest my-nlon)))))) This the case where the first item is not a list. Append won’t work! (needs lists!) Unless…

(define (flatten my-nlon) (cond ((empty? my-nlon) empty) ((list? (first my-nlon)) (append (flatten (first my-nlon)) (flatten (rest my-nlon)))) (else (append (list (first my-nlon)) (flatten (rest my-nlon)))))) We make the first item a list itself!

And so… (define (flatten my-nlon) (cond ((empty? my-nlon) empty) ((list? (first my-nlon)) (append (flatten (first my-nlon)) (flatten (rest my-nlon)))) (else (append (list (first my-nlon)) (flatten (rest my-nlon)))))) Note: we could have used cons just now…

And so… (define (flatten my-nlon) (cond ((empty? my-nlon) empty) ((list? (first my-nlon)) (append (flatten (first my-nlon)) (flatten (rest my-nlon)))) (else (cons (first my-nlon) (flatten (rest my-nlon)))))) Note: Version using cons to deal with first being a non-list (the last case of the cond.)

Let’s run both in DrScheme!

Cross-Referencing your Structures… Our data definitions are getting more complex. We just worked with a list that could contain as its data other lists. What if we made things even more complex?

The Family Tree, take two… Last time we considered the problem of a family tree, we defined it from our particular viewpoint. That is to say, we started with ourselves, and traced our lineage backwards through time. This fit quite nicely into the idea of a binary tree. After all, you’ll never have more than two biological parents….

But from the other direction… But what if we don’t want to go backwards through time, but instead go forward and trace a particular person’s descendents? Let’s see if we can start as before and fit our definition into something that looks like a binary tree…

The Parent What are some properties of a parent? 1) They have a name 2) They have a year that they were born 3) They have an eye color So far nothing different from how we defined a child in lecture 11.

4) A parent has children. Ooops. Here is a difference. Before we were able to assume that a child has no more than two biological parents. But how many children will a parent have? Can we limit ourselves to one, or two, or five?

Nope… We can’t limit a parent to a certain number of children. It varies from no children to some unknown number of children. Each parent has a different number. (Note: We are using the notion of “parent” to even include those with no children… Bear with me on the terminology.) Our binary tree model no longer works! So how can we fix our definition?

The new data definition… (define-struct parent (name born eyes children)) ;;A parent is a structure: ;;(make-parent n b e loc) ;;Where n & e are symbols, b is a number, and loc is a ;;list-of-children What’s a list-of-children?

;; a list-of-children is either: ;; 1) the empty list, empty ;; 2) (cons p loc) where p is a parent and loc is ;; a list-of-children

;; a list-of-children is either: ;; 1) the empty list, empty ;; 2) (cons p loc) where p is a parent and loc is ;; a list-of-children Remember, we’re creating an “ancestor” family tree. So every child of a previous generation will also be the parent of the next generation

So all together… (define-struct parent (name born eyes children)) ;;A parent is a structure: ;;(make-parent n b e loc) ;;Where n & e are symbols, b is a number, and loc is a ;;list-of-children ;; a list-of-children is either: ;; 1) the empty list, empty, or ;; 2) (cons p loc) where p is a parent and loc is ;; a list-of-children

So all together… (define-struct parent (name born eyes children)) ;;A parent is a structure: ;;(make-parent n b e loc) ;;Where n & e are symbols, b is a number, and loc is a ;;list-of-children ;; a list-of-children is either: ;; 1) the empty list, empty ;; 2) (cons p loc) where p is a parent and loc is ;; a list-of-children

What we’ve created… Are mutually referential data definitions. These two definitions refer to each other in their bodies. Which of course has implications for our template…

As we have two data definitions, we really need to have two different templates, one for each: (define (process-parent in-parent) …(parent-name in-parent)… …(parent-born in-parent)… …(parent-eyes in-parent)… …(parent-children in-parent)…) (define (process-loc in-loc) (cond ((empty? in-loc) …) (else …(first in-loc)… …(process-loc (rest in-loc))…)))

As we have two data definitions, we really need to have two different templates, one for each: (define (process-parent in-parent) …(parent-name in-parent)… …(parent-born in-parent)… …(parent-eyes in-parent)… …(parent-children in-parent)…) (define (process-loc in-loc) (cond ((empty? in-loc) …) (else …(first in-loc)… …(process-loc (rest in-loc))…))) Why don’t we call each template function from within the other?

Once again… The template not only reflects the data definition, but it also describes the generic case. It may not be the case that we’re necessarily going to call the process-parent function as we traverse a list of children. We may just want to count children. Or if we’re dealing with a parent structure, we may not wish to actually traverse the list of children. The template is generic. It’s up to you to build your function definition using it based on what you need to solve your specific problem.