Download Parameter Declaration - Data Structures and Programming Methodology - Solved Exams and more Exams Data Structures and Algorithms in PDF only on Docsity!
Fall 2004
Exam information
The average score on the exam was 17.9; the median was 17. (Were you to receive a grade of 23 on both your midterm exams, 45 on the final exam, plus good grades on homework and lab, you would receive an A–; similarly, a test grade of 16 may be pro- jected to a B–.)
Problem 1 (3 points)
This problem involved identifying an incorrect parameter declaration in a method that would cause two apparently identical LineNumber objects to not be identified as identical by the HashMap put method.
First, we can identify some noncandidates for the incorrectly declared method. We can’t touch anything in the HashMap class, and Expression methods aren’t involved in hash table insertion. That narrows down the problem to the LineNumber class.
We know that the put method, given a LineNumber and some associated value as argument, does the following:
- It calls LineNumber.hashCode to determine the hash value of the LineNumber.
- Using LineNumber.equals, it compares the LineNumber to everything in the table with the same hash value to see if a key/value pair with the given LineNumber as key is already in the table.
- If it finds a match, it replaces the associated value by the second argument to put. If not, it inserts the LineNumber/value pair into the table.
The get method does steps 1 and 2, and returns the associated value if it finds the LineNumber among the keys.
An important step in the design of hashable objects is the overriding of Object.hash- Code and Object.equals. Object.hashCode merely returns the machine address of the object; Object.equals returns true only when an object is compared to itself. The two LineNumber objects are seen as different by the Object methods: Object.hashCode returns two different hash values and Object.equals returns false when comparing them.
Thus a possible cause of the problem is the failure to override hashCode or equals. Supplying a parameter for hashCode or a parameter of an incorrect type to equals, e.g. saying
boolean equals (LineNumber n) ...
instead of
boolean equals (Object obj) ...
would produce the observed behavior; either error would result in an inability to retrieve the first LineNumber object from the table.
Mentioning the fact that the two LineNumbers were different objects earned you at least 1 point for this problem. Mentioning the relevance of the equals or hashCode method earned you at least 1 other point.
Fall 2004
Problem 2 (6 points)
You were to design a data structure named songsByGenre for songs that would yield fast retrieval by genre. A HashMap table that associates each genre with the collec- tion of songs of that genre would be the most appropriate data structure. One might use an ArrayList or a LinkedList to represent the collection. Adding a song to this data structure would involve the following put method:
void put (Song s) { LinkedList list = songsByGenre.get (s.genre ( )); if (list == null) { list = new LinkedList ( ); songsByGenre.put (s.genre ( ), list); } list.add (s); }
Parts a and b were each worth 3 points. Part a involved the design of the data struc- ture. If your design involved linear search through all the genres rather than the direct access of a hash table, you lost 1 point in this part. Part b involved the imple- mentation of the design as reflected by the put method. The answer
void put (Song s) { songsByGenre.put (s.genre ( ), s); }
was very common, perhaps due to a misconception that consecutive calls to Hash- Map.put with the same keys would somehow collect the corresponding values instead of replacing the mapping in the table. This answer earned 0 points in part b.
Fall 2004
Problem 4 (7 points)
This problem involved devising informative test cases for deletion in a quad tree. The test suite we were looking for was four out of the following five cases:
description situation tree transformation
deletion leaving an empty tree
replacement of two nodes by one in the next larger region
the previous case, with more than one level of the tree restructured
Fall 2004
You lost 1 point for a case that merely involved removal of a nonempty branch of the tree from a node with other children, on the grounds that it provides less evidence of correctness of the code than a removal that requires more radical restructuring of the tree. You received a 2-point deduction for a test case that was the same as one of your other cases except for the tree level of the node being deleted.
replacement of a full node by a mixed node with three children
the previous case, with more than one level of the tree restructured
description situation tree transformation
Fall 2004
Part a of this problem, the design of the delete method, was worth 5 points, and part b, the analysis of your method, was worth 2. In part b, a correct estimate of the time your algorithm would take was worth 2, an insufficiently specific estimate was worth 1, and an incorrect estimate received 0. Deductions in part a were as follows:
- Overlooking the need to consider both bubbling directions in the most efficient algorithm: –1.
- Using the O(n) heap recreation algorithm: –2.
- Using that algorithm but calling it “heap sort”: –3.
- Heap-inserting everything after position k: –3.
- Repeatedly promoting the larger child, starting at the deleted element: –3.
- Some other algorithm that either didn’t produce a heap or did so in O(n^2 ) time or worse: –4.
Insufficiently detailed explanations resulted in avoidable deductions for some of you. Examples of overly vague solutions included using the term “insert” without specify- ing whether you meant heap insertion or vector insertion, using “child” without say- ing which child, using “successor” without saying what that was or how you would find it, or calling one of the Data Structures into Java methods without giving its argument.
heap before deletion elements after deletion; violations of the order property are circled
