[Instructions] [Search] [Current] [Syllabus] [Links] [Handouts] [Outlines] [Labs] [More Labs] [Assignments] [Quizzes] [Examples] [Book] [Tutorial] [API]

Back to Introduction to Trees. On to Lab: Traversing and Iterating Trees.

**Held** Tuesday, April 27

**Summary**

- Implementing trees with arrays
- Heaps, an implementation of priority queues
- Heapsort, sorting using heaps
- Code templates due.

**Contents**

**Notes**

- I've received code files from many (but not all) of you. I'll have
them printed and online tomorrow.
- A number of you neglected to include parameters to your methods.
- The use of some of your classes is unclear. Some general documentation would have helped.
- I'll do my best to fix some problems before distributing the code.

- As you've noted, there are a number of terms we use when talking about trees. Here are some of them.
- The
*root*is the top or beginning of the tree. - A
*node*is a part of the tree. (While this has the same name as the nodes we often use to implement trees, you should think of it as independent of implementation.) - Most nodes have one or more
*children*. - Each node other than the root has a
*parent*. - Nodes without children are called
*leaves*. - Nodes with children are called
*interior nodes*. - The
*level*of a node is the number of steps from root to that node.- The root is at level 0.
- The direct children of the root are at level 1.
- The children of those nodes are at level 2.
- ...

- The
*depth*of a tree is the largest level of any node in the tree. - The
*size*of a tree is the number of nodes in the tree. - In a
*binary tree*, no node has more than two children.- The children are typically designated as
*left*and*right*.

- The children are typically designated as
- In a
*complete*tree, every level is full (all the interior nodes have the maximum number of children).

- When considering lists and other structures, we found ways to implement
the structures with both arrays and nodes.
- We've seen how to implement trees with nodes (in fact, that implementation is so natural that we use the term ``node'' in describing trees).
- Can we also implement trees with arrays?

- It turns out to be relatively easy to implement binary trees (particularly complete binary trees) with arrays.
- How?
- Assume we have a complete binary tree in that every interior (nonleaf) node has exactly two children.
- Number the nodes, starting at the top and working across each level.
(The root is node 0, its left child is node 1, the root's right child
is node 2, node 1's left child is node 3, node 1's right child is node
4, ...).
0 / \ 1 2 / \ / \ 3 4 5 6 / \ 7 8

- This numbering gives you the positions in the array for each element.
- (If you don't want to build complete trees and are willing to waste space, you can store a special value to represent ``nothing at this position''.)

- This provides a very convenient way of figuring out where children belong.
- The root of the tree is in location 0.
- The left child of an element stored at location
*i*can be found in location 2**i*+1. - The right child of an element stored at location
*i*can be found in location 2**i*+2 (also representable as 2*(*i*+1)).

- The parent of an element stored at location
*i*can be found at location`floor`

((*i*-1)/2). - Can we prove all this? Yes, but that's an exercise for another day.
- These properties make it simple to move the cursor around the tree
and to get values. However, they do make it more difficult to
do some operations. For example,
`setLeft`

and`setRight`

might require modifying a large number of cells (since we've decided that it*deletes*the old subtree).

- Heaps are a particular form of binary tree designed to provide quick access to the smallest element in the tree.
- Heaps are yet another structure that have multiple definitions.
- A heap is
- a
*binary tree*, - that is
*nearly complete*in that- at most one node has one child (the rest have zero or two)
- the nodes on the last level are at the left-hand-side of the level

- and that has the
*heap property*: the value stored in each node is smaller than or equal to the values stored below it.

- a
- Note that a ``local'' heap property (the value stored in a node is smaller
than the values stored in its children) is enough to guarantee a more
global heap property (the value stored in a node is smaller than the
values stored in its descendants).
- Consider the path; we can only be getting larger.

- Unlike many other data structures we've considered, heaps focus more on implementation than interface.
- Here are some heaps of varying sizes
2 2 2 2 2 2 3 / \ / / \ / \ / \ / \ 3 7 3 3 7 3 7 3 7 3 3 / \ | / / \ 9 7 8 9 9 7

- Here are some non-heaps. Can you tell why?
2 2 2 2 2 / \ / \ / \ /|\ | 3 7 9 7 7 3 3 3 3 3 / / \ / \ / \ / \ 9 8 8 9 7 9 7 4 7

- What good are heaps? They make it very easy to find the smallest element
in a group.
- That should remind you of priority queues.

- How do we modify heaps? Through insertion and deletion.
- How do we do insertion while maintaining the two key properties?
- We'll maintain one property (near-completeness) and then look to restore the other (heap order).

- When we add an element to the heap, we just need to put the element at
the end of the lowest level.
- If that level is full, we put it at the left end of the next level.

- After removing the smallest element from the heap, we have a ``hole'' at the top of the heap. We put the last element in the last level in that hole (which may sound like an odd idea, but at least it maintains the near-completeness property).
- Both of these operations may violate the heap order (in fact, the second one is almost guaranteed to violate heap order), so we need to rearrange the tree.
- This rearrangement is often called
*percolating*. When we put an element at the bottom, we percolate*up*. When we put an element at the top, we percolate*down*.

- Recall that to add an element to a heap we,
- put the element at the end of the lowest level and
- percolate up.

- Percolating up is fairly simple
- At each step, we compare the percolated node to its parent.
- If the percolated node is smaller (violating the heap property), we swap the two and continue up the tree.
- Otherwise, we're done, since the heap property is no longer violated.

- When we do the swap,
- the subtree that contains the old parent is clearly in heap order (the old parent was an ancestor to all the nodes in that subtree, and therefore smaller) and
- the present node is clearly smaller than both of its new subtrees (it's smaller than the old parent, and the old parent was smaller than everything else below it).

- Eventually, we stop (either because we no longer violate heap property or because we reach the root).
- Here's an example, based on inserting the values 5, 6, 4, 4, 7, 2
- Initial tree:
5

- Insert 6, no need to swap.
5 / 6

- Insert 4, swap with root.
5 4 / \ to / \ 6 4 6 5

- Insert 4, swap once
4 4 / \ / \ 6 5 to 4 5 / / 4 6

- Insert 7, no need to swap.
4 / \ 4 5 / \ 6 7

- Insert 2, need to percolate up to root.
4 4 2 / \ / \ / \ 4 5 to 4 2 to 4 4 / \ | / \ | / \ | 6 7 2 6 7 5 6 7 5

- Initial tree:
- How much time does this take? Well, the depth of a complete binary
tree with n nodes is O(log
_{2}(n)), and the algorithm may require swapping up from leaf to root, so the running time is also O(log_{2}(n)).

- Recall that to delete the smallest element of the heap we need to
- remove and remember the root;
- put the last element of the last level at the root;
- percolate down;
- return the old root.

- Percolating an element down is slightly more difficult than
percolating up, since there
are two possible subtrees to move to. As you might guess, you must
swap with the root of the smaller subtree and then continue within
that subtree.
- Why don't we worry about increasing the size of the wrong subtree? (As we did in building binary search trees.) Because we're not changing the size of the subtrees. We're swapping elements, but not adding them.

- In some sense, deletion reverses the process of insertion (delete last element in the heap vs. insert last element in heap; percolate down vs. percolate up).
- Here's a sample case of removal of least element.
2 ? 5 3 3 / \ / \ / \ / \ / \ 3 4 to 3 4 to 3 4 to 5 4 to 4 4 / \ | / \ | / \ / \ / \ 6 4 5 6 4 5 6 4 6 4 6 5

- What's the running time? O(log
_{2}(n)) again.

- We can use the heap structure to provide a fairly simple and quick
sorting algorithm. To sort a set of n elements,
- insert them into a heap, one-by-one.
- remove them from the heap in order.

- What's the running time?
- There are n insertions. Each takes O(log
_{2}(n)) time by our prior analysis. - There are n ``delete least'' operations.
Each takes O(log
_{2}(n)) by our prior analysis.

- There are n insertions. Each takes O(log
- Hence, we've developed yet another O(n*log
_{2}(n)) sorting algorithm. - It is not an in-place sorting algorithm, and does require O(n) extra space for the heap.
- Most people implement heap sort with array-based trees. Some even define heap sort completely in terms of the array operations, and forget the origins.

**History**

- Created Monday, January 11, 1999.
- Added short summary on Friday, January 22, 1999.
- Filled in the details on Tuesday, April 27, 1999. Much of the outline was based on outline 45 of CS152 98S.

Back to Introduction to Trees. On to Lab: Traversing and Iterating Trees.

[Instructions] [Search] [Current] [Syllabus] [Links] [Handouts] [Outlines] [Labs] [More Labs] [Assignments] [Quizzes] [Examples] [Book] [Tutorial] [API]

**Disclaimer** Often, these pages were created "on the fly" with little, if any, proofreading. Any or all of the information on the pages may be incorrect. Please contact me if you notice errors.

This page may be found at http://www.math.grin.edu/~rebelsky/Courses/CS152/99S/Outlines/outline.46.html

Source text last modified Tue Apr 27 09:59:43 1999.

This page generated on Tue Apr 27 10:09:45 1999 by SiteWeaver. Validate this page's HTML.

Contact our webmaster at rebelsky@math.grin.edu