# Exam 2: Objects, Linear Structures, and Algorithms

Distributed: Friday, April 7, 2006
Due: 11:00 a.m., Friday, April 14, 2006
Extensions in extreme circumstances only.

This page may be found online at `http://www.cs.grinnell.edu/~rebelsky/Courses/CS152/2006S/Exams/exam.02.html`.

Contents

## Preliminaries

The instructions on this exam are slightly different than the instructions on the other exam. Those who correctly summarize the differences on the cover page of their exam will earn two extra points on this exam.

There are four problems on the exam. Some problems have subproblems. Each problem is worth twenty-five (25) points. The point value associated with a problem does not necessarily correspond to the complexity of the problem or the time required to solve the problem.

Experience shows that different people find different problems complex. Hence, if you get stuck on an early problem, try moving on to another problem and let your subconscious work on the early problem. (You'll also get a better sense of accomplishment if you can find at least one problem that you can solve early.)

This examination is open book, open notes, open mind, open computer, open Web. However, it is closed person. That means you may not talk to other people about the exam. Other than as restricted by that limitation, you should feel free to use all reasonable resources available to you. As always, you are expected to turn in your own work. If you find ideas in a book or on the Web, be sure to cite them appropriately.

Although you may use the Web for this exam, you may not post your answers to this examination on the Web (at least not until after I return exams to you). And, in case it's not clear, you may not ask others (in person, via email, via IM, by posting a please help message, or in any other way) to put answers on the Web.

This is a take-home examination. You may use any time or times you deem appropriate to complete the exam, provided you return it to me by the due date. Experience from the first exam suggests that you should begin this exam early, or at least look at the problems early.

I expect that someone who has mastered the material and works at a moderate rate should have little trouble completing the exam in a reasonable amount of time. In particular, this exam is likely to take you about four to six hours, depending on how well you've learned topics and how fast you work. You should not work more than eight hours on this exam. Stop at eight hours and write There's more to life than CS and you will earn at least 75 points on this exam.

I would also appreciate it if you would write down the amount of time each problem takes. Each person who does so will earn two points of extra credit. Since I worry about the amount of time my exams take, I will give two points of extra credit to the first two people who honestly report that they've spent at least five hours on the exam or completed the exam. (At that point, I may then change the exam.)

You must include both of the following statements on the cover sheet of the examination. Please sign and date each statement. Note that the statements must be true; if you are unable to sign either statement, please talk to me at your earliest convenience. You need not reveal the particulars of the dishonesty, simply that it happened. Note that inappropriate assistance is primarily assistance from anyone other than Professor Rebelsky (that's me). Inappropriate assistance also includes assistance given to another member of the class.

1. I have neither received nor given inappropriate assistance on this examination.
2. I am not aware of any other students who have given or received inappropriate assistance on this examination.

Because different students may be taking the exam at different times, you are not permitted to discuss the exam with anyone until after I have returned it. If you must say something about the exam, you are allowed to say This is among the hardest exams I have ever taken. If you don't start it early, you will have no chance of finishing the exam. You may also summarize these policies (but not the changes since the previous exam). You may not tell other students which problems you've finished. You may not tell other students how long you've spent on the exam.

You must both answer all of your questions electronically and turn in a printed version of your exam. That is, you must write all of your answers on the computer, print them out, number the pages, put your name on every page, and hand me the printed copy. You must also email me a copy of your exam by copying the various parts of your exam and pasting it into an email message. Put your answers in the same order as the problems. Please write your name at the top of each sheet of the printed copy. Failing to do so will lead to a penalty of two points. Turning your exam in in reverse order will also lead to a penalty, albeit an unspecified one.

In many problems, I ask you to write code. Unless I specify otherwise in a problem, you should write working code and include examples that show that you've tested the code. Unless I specify otherwise, you should document your code (using javadoc-style comments for classes, fields, and methods and slash-slash comments for particular algorithm details and end braces).

Just as you should be careful and precise when you write code and documentation, so should you be careful and precise when you write prose. Please check your spelling and grammar. Since I should be equally careful, the whole class will receive one point of extra credit for each error in spelling or grammar you identify on this exam. I will limit that form of extra credit to five points.

I will give partial credit for partially correct answers. You ensure the best possible grade for yourself by emphasizing your answer and including a clear set of work that you used to derive the answer.

I may not be available at the time you take the exam. If you feel that a question is badly worded or impossible to answer, note the problem you have observed and attempt to reword the question in such a way that it is answerable. If it's a reasonable hour (before 10 p.m. and after 8 a.m.), feel free to try to call me in the office (269-4410) or at home (236-7445). I also respond well to email questions.

I will also reserve time at the start of classes next week to discuss any general questions you have on the exam.

## Preparation

In this laboratory, you will use project named `Exam2` with a host of packages, including. `username.analysis`, `username.functions`, `username.linear`, `username.tests`, and `username.util`.

a. In a terminal window, type

```/home/rebelsky/bin/exam2
```

You should see messages about files being copied.

b. Start Eclipse.

c. In Eclipse, build a project named Exam2 from `/home/username/CSC152/Exam2`.

d. You are now ready to begin the examination.

## Problems

### Problem 1: Visual Support for Algorithm Analysis

Topics: Input/Output, Running-time analysis, Inheritance, Polymorphism

Graham and Gretta Grapher are disappointed with the current support we seem to have for analyzing algorithms. They note that

It's all well and good that we can determine the number of steps or the running time of an algorithm with respect to the input size, but we would certainly understand the relationship better if we could easily graph the results.

For example, they would like to write something like the following.

```for (int n = 0; n < BOUND; n = update(n)) {
long start = System.currentTimeMillis();
for (int rep = 0; rep < REPETITIONS; rep++) {
// Run the algorithm on input of size n
} // for each repetition
long finish = System.currentTimeMillis();
long costInMicros = (1000*(start-finish))/REPETITIONS;
graph.plot(n, costInMicros, "*");
} // for each n
```

They consult their friend Terry Texter, who develops a simple text-based screen and graph, which you can find as username.analysis.Screen.java and username.analysis.Graph.java.

Graham and Gretta giggle in response to Terry's generosity, and then quickly rewrite the program used to analyze the exponentiation algorithms. You can find their rewritten code as username.tests.AnalyzeExpt.java.

a. Unfortunately, they observe that Terry's graph does a one-to-one mapping of value to position. Since they use a maximum n of 1000, and the screen is typically only 80 columns wide, they find the results, well, less than satisfactory. They turn to you for help.

Please write (and test) a new class, `ScaledGraph`, that lets the client specify that maximum x and y values along with the width and height of the graph. For example, if we made the graph 80 columns wide and 20 columns high but specified the maxium x as 800 and the maximum y as 800, then the point (350,75) would be plotted at character position (35,2).

b. Graham and Gretta are overjoyed by your genius. Of course, that means that they want to do more. They say We can plot points. Can we now easily graph functions? They begin to do so by hand, but quickly realize that they would be much better off adding a `graph(Function f)` method to `Graph` or `ScaledGraph` (or, better yet, having you add such a method).

Unfortunately, their experience in Scheme has misled them. Java does not provide an immediately obvious way to pass functions as parameters. They turn to their friends, Otto and Oxana Overkill, for ideas.

Otto and Oxana say

Hey, you remember that strange `TextBlock` thingy that Rebelsky had us do? I bet we could do the same thing with functions, and require each function to include an `apply(int x)` method.

They quickly throw together a `username.functions` package, that includes a UnaryIntegerFunction.java interface; some basic functions, such as IdentifyUIF.java and LogUIF.java; and even some ways of combining functions, such as ProductUIF.java and ComposeUIF.java.

They even write a few programs to test their ideas. The first simply builds some functions and applies them to a variety of values. You can find that simple test at username.tests.TestFuns.java.

More importantly, they write a simple program that graphs some sample functions, which you may find at. username.tests.GraphFuns.java.

Using their ideas, add a `graph(UnaryIntegerFunction f)` method to `ScaledGraph` and test that method.

c. Optional! Five points of extra credit.

Graham and Greta generally appreciate what you've done, but they note that one problem is that they are now limited to what is often called a linear-linear graph. That is, the offset of each point from the origin is linear in the x value and the y value. As die-hard graphers, they have used a variety of other kinds of graph paper, such as log-linear, in which the x distance of a point from the origin depends on the log of x, rather than on x.

Fortunately, the `UnaryIntegerFunction` type that Otto and Oxana wrote for the previous subproblem should help. That is, when someone constructs a graph, they might also specify a function by which one should scale values on the x and y axes.

Write and test a new graphing class, `FancyGraph`, whose constructor takes six parameters

• int width
• int height
• int maxX
• int maxY
• UnaryIntegerFunction mungeX
• UnaryIntegerFunction mungeY

and which applies mungeX and mungeY to every point before plotting it.

### Problem 2: Random Linear Structures

Topics:: Linear structures, Array-based implementations of ADTs

Randy Random loves that we have built so many kinds of linear structures. However, Randy notes that we've left out one kind; one close to Randy's heart. Randy notes, When I make a to-do list, I like to get things back in an unpredictable order.

Your rebellious professor decides that you should rapidly respond to this request by building the `RandomLinearStructure` class that does what Randy wants. That is, a call to `get` for members of this class should return some element of the structure, but one that is difficult to predict. (In particular, you should choose every element in the structure with equal probability.)

Write and test this class, using a Vector as the underlying structure. In doing so, please make sure that both `put` and `get` are constant-time operations (except when the Vector expands).

Note that removing an object from the middle of a Vector is not a constant-time operation, but removing the last element is.

### Problem 3: Dynamic Arrays

Topics: Arrays, Stacks, Running-time analysis

Minnie and Milton Minimalist suggest that, although we use Vectors for problems like the previous one, Vectors are probably overkill. That is, the only reason we really use Vectors is that we want dynamic arrays, arrays that expand when we need more space. They suggest that we need a `DynamicArray` class, which provides only `set`, `get`, and `size`.

Of course, as minimalists, they'd rather let you develop the code than develop it themselves. Fortunately, you find that someone has started to answer their request, and created the files username.util.SimpleArray.java and username.util.DynamicArray.java.

a. On further inspection, you note that the implementer cleverly forgot to implement the `ensureMinimumSize(int min)` method. Implement that method so that it expands the underlying `SimpleArray` to a size of exactly `min`.

b. Steve and Stella Stacker quickly implement a stack that uses your new `DynamicArray` class. You can find their implementation as username.util.ArrayBasedStack.java. You can find a test as username.tests.TestStack.java.

Unfortunately, they quickly discover that the `reverse` procedure in `TestStack` seems to have a running time quadratic in the input size, rather than the linear running time they expected.

i. Confirm or refute their experimental observation.

ii. Explain their experimental observation.

iii. Indicate what needs to be changed (and how) to make `reverse` linear. (Note that the change should not be in `reverse`, but instead in `Stack` or `DynamicArray`.)

### Problem 4: Heapsort

Topics: Linear structures, Sorting, Running-time analysis

As you may recall, heaps provide a relatively efficient implementation of priority queues. A heap is a form of binary tree. Heaps must be nearly complete. That is, all rows but the last row are complete and the last row has gaps only at the right). Heaps must also have the heap property. That is, the value stored in a node must be smaller than or equal to the values stored in its descendants. Near-completeness guarantees that the depth is in O(log2(n)). The heap property guarantees that we can easily find the smallest value (after all, it's at the root of the tree).

To get the smallest value from the heap, we remove the value at the root (constant time), move the last value in the last row to the root (constant time), and then swap down, moving that value to its appropriate place in the heap (time proportional to depth).

To add a value to the heap, we put it at the the end of the last row (constant time) and then swap up moving that value to its appropriate place in the heap (time proportional to depth).

In class, I suggested that we could implement heaps using `TreeNode` structures with a value, left child, and right child. However, Peter and Petra Pedant note that most people use arrays, rather than actual trees, to store heaps, and that I should teach you about that variant.

The Pedants note that it is much easier to store heaps in arrays, with level i immediately before level i+1. That is, the root is at position 0. The left and right children of the root are at positions 1 and 2. The left and right children of the node at position 1 are at positions 3 and 4. The left and right children of the node at position 2 are at positions 5 and 6. And so on and so forth.

Consider the following heap:

```            A
/       \
B           F
/   \       /   \
C     X     G     K
/\    /\     /\
D  D  Y  Z   H  I
```

We can represent the position of each node as follows.

```            0
/       \
1           2
/   \       /   \
3     4     5     6
/\    /\     /\
7  8  9  10  11 12
```

Hence, the array might have the form

```  0   1   2   3   4   5   6   7   8   9   10  11  12  13  14  ...
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---
| A | B | F | C | X | G | K | D | D | Y | Z | H | I |   |   |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---
```

Why would we choose to store the heap in an array? One reason is that it saves space. A better reason is that it simplifies a common suboperation in heaps. You may recall that we add new elements to the end of the last row, and we grab the last element in the last row when deleting (we don't delete it, we shove it at the root). If we store the heap in an array and keep track of how many values there are, we can easily find the last thing.

But what do we do about finding parents and children? Some simple math suggests that the index of the left child of the node at index i is 2*i+1 and the index of the right child is 2*i+2. Similarly, the index of the parent of the node at position i is the floor of (i-1)/2.

I've begun to implement the Heap data structure, which you will find in username.linear.Heap.java. I've even written a simple test, which you will find at username.tests.TestHeap.java.

a. As you can see, I have neglected to implement the `swapUp` and `swapDown` operations. Implement those operations.

b. In class, I claimed that we could use heaps to implement a relatively fast sorting strategy. To sort a group of values, shove them all into the heap and then take them out in order. Implement that strategy. That is, write a method that takes a collection of values (e.g., an array) as input, puts all the values in the collection into a heap, and then puts the values from the heap back into the collection in sorted order.

c. I also claimed that this strategy for sorting should take time proportional to O(nlog2n). Gather experimental data to verify or refute that claim.

These are some of the questions students have asked about the exam and my answers to those questions.

General Questions

Sam, you made a lot of mistakes on this exam. Can we get an extra point for every five beyond the first six?
Yes.
What happens if we only get four additional errors (4/5 of a point)?
I round down.
What if you make mistakes in the Q&A section, or mistakes in your HTML?
You probably won't get credit for those.
How do we gather data for the problems that ask about running time?
Pick a variety of problem sizes. For each size, determine the start time, run the algorithm lots of times, determine the end time, subtract.

Problem 1: Graphing

Can you give a more general example?
Sure. Suppose that we're graphing in 80 columns and 20 rows, and the client decides that the maximum X is 1000 and the maximum Y is also 1000. The 80th column needs to represent 1000 and the 20th row needs to represent 1000. Hence, we should scale the X value by 80/1000 (= 2/25) and the Y value by 20/1000 (= 1/50). If someone asks to graph (30, 300), we multiply 30 by 2/25 and get "about 2" and 300 by 1/50 and get "about 6". We therefore plot it in the second column and the 6th row.

Problem 3: Random Linear Structures

On problem 2, does `peek` have to return the same value as the next call to `get`.
The two methods need not return the same value. The `peek` method, like the `get` method should return a hard-to-predict value. Of course, if you want to carefully write your code so that `peek` predicts the value returned by `get`, that's cool, too.
Okay, I know how to solve the problem if you let me use `remove` to remove the random element I've selected, but I understand that `remove` is not a constant-time operation. What should I do?
I discussed that issue in the first lecture on implementing priority queues.

Problem 3: Dynamic Arrays

I was trying to make an array in a generic class, using T as the base type of the array. Can I do that?

Java will not permit you to do so.

How do I get around that problem?

Make an array of objects, and cast values when you remove them. See `SimpleArray.java` for more details

. Problem 4: Heaps

On problem 4, I had a question about implementing `swapDown`. How do I decide whether to compare the parent value to the left child or the right child or both?
You should compare it to the smaller child.
How do I determine whether there are any children or whether there's only one child?
To determine whether there is only one child, get the index of the right child and compare it to the number of elements in the heap. If the index of the right child is smaller, then there is a right child. Otherwise, there is not a right child. You can use a similar technique to determine if there are any children.

## Errors

Here you will find errors of spelling, grammar, and design that students have noted. Remember, each error found corresponds to a point of extra credit for everyone. I limit such extra credit to six points.

• Sam can't even write instructions for the preparation correctly [EJ, 1 point]
• In AnalyzeExpt.java, Sam wrote something like "The number of times to repeat a tests so that too-quick tests aren't too fast too measure." That phrase should, of course, read "The number of times to repeat a test so that too-quick tests aren't too fast to measure." [LH, 2 points]
• The link to `Graph.java` actually goes to `Screen.java`. [CW, 1 point]
• Although "access" and "axes" may sound similar (at least if you mumble), they are different. [EL, 1 point]
• Too embarassing to describe. [EL, 1 point]
• "They can might also" should probably not have two modifiers, at least in standard English. [BM, 1/5 point]
• In `TestStack` and `TestFunctions`, Sam cleverly wrote A simple tests of rather than A simple test of [LH, 2/5 point]
• In `Graph`, the wonders of cut-and-paste led Sam to incorrectly comment the end brace for the `Graph` constructor with `// Screen`. [EJ, 1/5 point]
• In `TestSimpleArray`, the lines to print `zeroToNine` and `zeroToTen` print out `ints` instead. [ST, 1/5 point]
• rather linear running time that they expected should be rather than the linear running time that they expected [LK, 1/5 point]
• In `Graph`, the wonders of cut-and-paste led Sam to incorrectly comment the end brace for `plot` with `// setCharAt`. [IBR, 1/5 point]

Moral: SamR does too much cut-and-paste when he is coding.

## History

Late March to Early April 2006 [Samuel A. Rebelsky]

• Basic design of problems.

Wednesday, 5 April 2006 [Samuel A. Rebelsky]

• Began to write supporting code.

Thursday, 6 April 2006 [Samuel A. Rebelsky]

• Finished writing supporting code.
• Chose and designed four basic problems.
• Copied the heapsort problem from a previous exam, but rewrote significantly.

Friday, 7 April 2006 [Samuel A. Rebelsky]

• Finished writing.
• Released.

Sunday, 9 April 2006 [Samuel A. Rebelsky]

• Noted correction.

Monday, 10 April 2006 [Samuel A. Rebelsky]

• More corrections.

Tuesday, 11 April 2006 [Samuel A. Rebelsky]

• Corrections to grammar in commments for code. (Whoops.)
• New questions. (Some real, some simulated.)
• Segmented questions and answers by problem.

Wednesday, 12 April 2006 [Samuel A. Rebelsky]

• More code corrections.

Disclaimer: I usually create these pages on the fly, which means that I rarely proofread them and they may contain bad grammar and incorrect details. It also means that I tend to update them regularly (see the history for more details). Feel free to contact me with any suggestions for changes.

This document was generated by Siteweaver on Tue May 9 08:30:57 2006.
The source to the document was last modified on Thu Apr 13 10:24:41 2006.
This document may be found at `http://www.cs.grinnell.edu/~rebelsky/Courses/CS152/2006S/Exams/exam.02.html`.

You may wish to validate this document's HTML ; ; Check with Bobby

Samuel A. Rebelsky, rebelsky@grinnell.edu