46B CS Introduction to Data Structures
Fall 2007 November 4, 2007: 3 page(s)
Programming Assignment 3: due before 7:00 p.m. November 9, 2007
So far in class, we have seen several data structures which can be used to store and look up elements. Fundamentally, many of these data structures can be used to do many of the same tasks: store items, add items to be stored, nd items, remove items, etc. In this homework assignment, we will try to compare how several of the dierent data structures perform against each other. The homework will consist of running the data structures through a series of tests, in order to see how quickly they work. In a future assignment, you will be asked some questions related to the test results. Most of these data structures are already dened for generic types, but for this assignment, you will only be storing Integers. You will compare the runtimes of several classes: 1. LinkedList 2. OrderedList (You need to implement this, but see Section 4.7 of the text, where you will need the add, and contains methods. It isnt really a subclass of LinkedList, since some LinkedList operations dont make sense here: for instance, adding can only go to the correct sorted order, not an arbitrary order. Instead, delegate to the LinkedList class. Note, most of the code for this can be downloaded directly from the textbook student companion website. You may use that if you wish.) In the case of the contains method, do not simply delegate it to the LinkedList class: instead, if you are searching from the front of the list, once you get past where the element should have been, you can exit without looking at the rest of the objects. (That is, if the list has 1, 5, 57, 89, 100, 176, 225, . . . , and we are looking for 95, we know 95 is not in the list once we see 100.) 3. ArrayList 4. OrderedArrayList (You need to implement this. Again, you will delegate to the ArrayList class, rather than being a subclass of it.) The contains method should use binary search, but not the one in the Java Arrays class; to use that one, things need to be in an actual array. Instead, you can modify the binarySearch in Komann chapter 7 (also at the student website) to work on your OrderedArrayList rather than just on an Array. You cannot copy it over to an array before using binary search, because the copy will take too long. 5. BinarySearchTree (You need to implement, See Section 8.4 of the text, you will need the add and contains methods. Note, most of the code for this can be downloaded directly from the textbook student companion website. You may use that if you wish. You will need to code the contains method.) We would like to time how long the calls take. To get this, we will use the Date class (java.util.Date). (There may be other, better ways to do this, but lets go with this one.) Here, a call to constructor Date() will allocate a Date object with the current time, at millisecond accuracy. The idea is basically the following: Do any initialization work you want to here Date startDate = new Date(); run some code here Date endDate = new Date(); long runtimeInMilliseconds = endDate.getTime() - startDate.getTime(); will leave the variable runtimeInMilliseconds as the runtime of the middle part of code. In our case, this middle part will have the test we are currently timing. To be fair, we should really run each test several times, and consider a median runtime: running a test just once leaves the possibility that the machine was slow at that moment due to other events taking place. (We might consider more sophisticated tests which actually measure how much CPU is being used by a particular process, but here, we will just use time.) To further make our tests fair, we should only run them with minimal other things happening on the machine while they run. (No watching videos while you benchmark your data structures.) We should also think about just testing one data structure at a time: if several are tested, the rst ones may have an advantage, as they use up some memory that was free, while later tests may have the disadvantage of needing to swap to get new memory. Or, later data structures may have an advantage, in that maybe the kernel scheduler devotes more resources to the java program after it uses a certain amount of CPU. These issues are out of your control, and beyond the scope of this class. To take them of out the equation, lets just test one data structure at a time. So, pseudocode for one test case might look like the following. Assume that NUM TRIALS= 5 is a nal integer, dened to be the number of trials you will have for each data structure for each test, and DataStructure is the data structure you are testing, such as BinarySearchTree. ll up the array toBeInserted here for your given test case. ll up the toBeTested array for your given test case here. Date startDate; Date endDate; 1
DataStructure Test = new DataStructure Integer (); int trials = 0; int successes = 0; long results[NUM TRIALS]; for(int i = 0; i <NUM TRIALS; i + +) { startDate = new Date(); for(j : toBeInserted) Test.add((Integer) j); for(j : toBeTested) { trials++; if(Test.contains((Integer) j)) successes++; } endDate = new Date(); long results[i] = endDate.getTime() - startDate.getTime(); } Give average runtime (from results) Give median runtime (from results) For the above tests, the assumption is that the Integer[] toBeInserted contains n items that you are about to insert. You should run it for each data structure type. You should do this without coding it once for each type, but instead by reusing code. For instance, based on command-line arguments, you could use conditionals (if statements) to decide what type of data structure Test is, and then the rest of the code would run regardless of what data structure it is. (Also, for each test, print the number of successes and the number of trials, ask kept in those integers.) For each data structure, you should try the following test cases: 1. Add, in order, the odd integers 1 to 9999. Lookup each of those (odd) numbers twice each. 2. Add, in order, the odd integers 1 to 9999. Lookup each even number, 2 to 10000, twice each. 3. Add, in order, the odd integers 1 to 1999. Lookup each of those (odd) numbers 10 times each. 4. Add, in order, the odd integers 1 to 1999. Lookup each even number, 2 to 2000, 10 times each. 5. Add, in order, the odd integers 1 to 1999. Lookup just the number 3, 10000 times. 6. Add, in order, the odd integers 1 to 1999. Lookup just the number 4, 10000 times. 7. Add, in order, the odd integers 1 to 1999. Lookup just the number 1997, 10000 times. 8. Add, in order, the odd integers 1 to 1999. Lookup just the number 1998, 10000 times. 9-16 The same tests as above, except that the integers should not be added in order. (They can still be looked up in whatever order is easiest.) Instead, use the following code to ll up an array called toBeInserted, and then just insert items from the array, where n is the number of items in the array (5...