1
+
2
+ <!-- saved from url=(0061)http://coursera.cs.princeton.edu/algs4/checklists/queues.html -->
3
+ < html > < head > < meta http-equiv ="Content-Type " content ="text/html; charset=UTF-8 ">
4
+ < title >
5
+ Programming Assignment 2 Checklist: Deques and Randomized Queues
6
+ </ title >
7
+ </ head >
8
+
9
+ < body >
10
+
11
+ < p > < br >
12
+ </ p > < h2 >
13
+ Programming Assignment 2 Checklist: Deques and Randomized Queues
14
+ </ h2 >
15
+
16
+ < p > < br >
17
+
18
+ < table border ="0 " cellpadding ="2 " cellspacing ="0 " width ="100% ">
19
+ < tbody > < tr align ="left ">
20
+ < td bgcolor ="000000 ">
21
+ < font size ="+0 " face ="helvetica " color ="ffffff ">
22
+ < center > < b > Frequently Asked Questions</ b > </ center >
23
+ </ font > </ td > </ tr > </ tbody > </ table >
24
+
25
+ </ p > < p > < b > Should I use arrays or linked lists in my implementations?</ b >
26
+ In general we don't tell you < em > how</ em > to implement your data structures—you
27
+ can use arrays, linked lists, or maybe even invent your own new structure provide
28
+ you abide by the specified time and space requirements.
29
+ So, before you begin to write the code, make sure that your data structure
30
+ will achieve the required resource bounds.
31
+
32
+ </ p > < p > < b > How serious are you about not calling any external library function other than those in < tt > stdlib.jar</ tt > ?</ b >
33
+ You will receive a substantial deduction.
34
+ The goal of this assignment is to implement data types from first principles, using
35
+ resizing arrays and linked lists—feel free to use
36
+ < a href ="http://docs.oracle.com/javase/7/docs/api/java/util/LinkedList.html "> java.util.LinkedList</ a >
37
+ and
38
+ < a href ="http://docs.oracle.com/javase/7/docs/api/java/util/ArrayList.html "> java.util.ArrayList</ a >
39
+ on future programming assignments.
40
+ We also require you to use < tt > StdIn</ tt > (instead of
41
+ < a href ="http://docs.oracle.com/javase/7/docs/api/java/util/Scanner.html "> java.util.Scanner</ a > )
42
+ because we will intercept the calls to < tt > StdIn</ tt > in our testing.
43
+
44
+ </ p > < p > < b >
45
+ Can I add extra public methods to the < tt > Deque</ tt > or
46
+ < tt > RandomizedQueue</ tt > APIs?
47
+ Can I use different names for the methods?</ b >
48
+ No, you must implement the API exactly as specified.
49
+ The only exception is the < tt > main()</ tt > method, which you should use for
50
+ unit testing.
51
+
52
+ <!--
53
+ <p><b>If a client creates two randomized queue iterators, should
54
+ they return the items in the same order?</b>
55
+ No, each should return them in random order, independent
56
+ of the other.
57
+ -->
58
+
59
+
60
+ </ p > < p > < b > What is meant by uniformly at random?</ b >
61
+ If there are < em > n</ em > items in the randomized queue, then you should choose each one
62
+ with probability 1/< em > n</ em > , up to the randomness of < tt > StdRandom.uniform()</ tt > ,
63
+ independent of past decisions.
64
+ You can generate a pseudo-random integer between 0 and < em > n</ em > −1 using
65
+ < tt > StdRandom.uniform(n)</ tt > from
66
+ < a href ="http://algs4.cs.princeton.edu/code/javadoc/edu/princeton/cs/algs4/StdRandom.html "> < tt > StdRandom</ tt > </ a > .
67
+
68
+ </ p > < p > < b > Given an array, how can I rearrange the entries in random order?</ b >
69
+ Use < tt > StdRandom.shuffle()</ tt > —it implements the Knuth shuffle
70
+ discussed in lecture and runs in linear time. Note that depending on your implementation,
71
+ you may not need to call this method.
72
+
73
+ </ p > < p > < b > What should my deque (or randomized queue) iterator do if the deque
74
+ (or randomized queue) is structurally modified
75
+ at any time after the iterator is created (but before it is done iterating)?</ b >
76
+ You don't need to worry about this in your solution.
77
+ An industrial-strength solution (used in the Java libraries)
78
+ is to make the iterator < em > fail-fast</ em > : throw a
79
+ < tt > java.lang.ConcurrentModificationException</ tt > as soon as this is detected.
80
+
81
+ </ p > < p > < b > Why does the following code lead to a
82
+ < tt > generic array creation</ tt > compile-time error when < tt > Item</ tt > is a generic
83
+ type parameter?</ b >
84
+
85
+ </ p > < blockquote >
86
+ < pre > Item[] a = new Item[1];
87
+ </ pre >
88
+ </ blockquote >
89
+
90
+ Java prohibits the creation of arrays of generic types. See the
91
+ < a href ="http://algs4.cs.princeton.edu/13stacks/index.php#Q+A "> Q+A in Section 1.3</ a >
92
+ for a brief discussion. Instead, use a cast.
93
+
94
+ < blockquote >
95
+ < pre > Item[] a = (Item[]) new Object[1];
96
+ </ pre >
97
+ </ blockquote >
98
+
99
+ Unfortunately, this leads to a compiler warning.
100
+
101
+ <!---
102
+ <p><b>I'm using a linked list and don't like dealing with these special cases when the list is empty or almost
103
+ empty. Is there some way to simplify them?</b> Yes. One common method is to include sentinel nodes. A sentinel node
104
+ is just a special node created by the constructor which is never removed, and which contains dummy data which is
105
+ never used. The trick is that your head (and tail, if applicable) pointers always point at these special sentinel
106
+ nodes, even if the list is empty. In other words, the head (and tail) pointers are never null, thus avoiding the
107
+ need to check to see if the head (or tail) is null.
108
+ -->
109
+
110
+ < p > < b > The compiler says that my program uses unchecked or unsafe operations
111
+ and to recompile with -Xlint:unchecked for details.</ b >
112
+ Usually this means you did a potentially unsafe cast.
113
+ When implementing a generic stack with an array, this is unavoidable since
114
+ Java does not allow generic array creation. For example, the compiler outputs
115
+ the following warning with
116
+ < a href ="http://algs4.cs.princeton.edu/13stacks/ResizingArrayStack.java.html "> ResizingArrayStack.java</ a > :
117
+
118
+ </ p > < blockquote >
119
+ < pre > % javac ResizingArrayStack.java
120
+ Note: ResizingArrayStack.java uses unchecked or unsafe operations.
121
+ Note: Recompile with -Xlint:unchecked for details.
122
+
123
+ % javac -Xlint:unchecked ResizingArrayStack.java
124
+ ResizingArrayStack.java:25: warning: [unchecked] unchecked cast
125
+ found : java.lang.Object[]
126
+ required: Item[]
127
+ a = (Item[]) new Object[2];
128
+ ^
129
+ ResizingArrayStack.java:36: warning: [unchecked] unchecked cast
130
+ found : java.lang.Object[]
131
+ required: Item[]
132
+ Item[] temp = (Item[]) new Object[capacity];
133
+ ^
134
+ 2 warnings
135
+ </ pre >
136
+ </ blockquote >
137
+
138
+
139
+ < p >
140
+ You should not make any other casts.
141
+
142
+
143
+ </ p > < p > < b > Checkstyle complains that my nested class' instance variables must be
144
+ private and have accessor methods that are not private. Do I need to make them private? </ b >
145
+ No, but there's no harm in doing so.
146
+ The access modifier of a nested class' instance variable
147
+ is irrelevant—regardless of its access modifiers, it can be accessed
148
+ anywhere in the file. (Of course, the enclosing class' instance
149
+ variables should be private.)
150
+
151
+ </ p > < p > < b > Can a nested class have a constructor?</ b >
152
+ Yes.
153
+
154
+ </ p > < p > < b > What assumptions can I make about the input to < tt > Permutation</ tt > ?</ b >
155
+ Standard input can contain any sequence of strings.
156
+ You may assume that there is one integer command-line argument < em > k</ em >
157
+ and it is between 0 and the number of strings on standard input.
158
+
159
+ </ p > < p > < b > Will I lose points for loitering?</ b >
160
+ Yes. <!-- See p. 137 of the textbook for a discussion of loitering. -->
161
+ Loitering is maintaining a useless reference to an object that could otherwise be garbage collected.
162
+
163
+ </ p > < p >
164
+
165
+ < table border ="0 " cellpadding ="2 " cellspacing ="0 " width ="100% ">
166
+ < tbody > < tr align ="left ">
167
+ < td bgcolor ="000000 ">
168
+ < font size ="+0 " face ="helvetica " color ="ffffff ">
169
+ < center > < b > Possible Progress Steps</ b > </ center >
170
+ </ font > </ td > </ tr > </ tbody > </ table >
171
+ </ p > < p >
172
+
173
+ These are purely suggestions for how you might make progress. You do
174
+ not have to follow these steps. These same steps apply to each of the two data
175
+ types that you will be implementing.
176
+
177
+ </ p > < ol >
178
+
179
+ < p > </ p > < li > < b >
180
+ Make sure you understand the performance requirements for both < tt > Deque</ tt > and < tt > RandomizedQueue</ tt > .</ b >
181
+ <!--
182
+ Your Deque should use space proportional to the number of items <i>currently</i> in the deque, and each
183
+ operation must complete in <i>constant worst-case time</i>. Your Deque iterator must support each iteration
184
+ operation (including construction) in <i>constant worst-case time</i>, and use a <i>constant</i> amount of
185
+ extra space per iterator. Your RandomizeQueue should use space proportional to the number of items
186
+ <i>currently</i> in the queue, and each operation should complete in <i>constant <b>amortized</b> time</i>.
187
+ Your RandomizedQueue iterator implementation must support each iteration operation (<b>excluding</b>
188
+ construction) in <i>constant worst-case time</i>, and use a <i>linear</i> amount of extra space per iterator.-->
189
+ They are summarized in the table below.
190
+ < em > Every detail in these performance requirements is important.
191
+ Do not proceed until you understand them.</ em >
192
+
193
+ < center >
194
+ < p > < table border ="1 " cellpadding ="4 " cellspacing ="0 ">
195
+ < tbody >
196
+ <!-- Results table headers -->
197
+ < tr >
198
+ < th > </ th >
199
+ < th > Deque</ th >
200
+ < th > Randomized Queue</ th >
201
+ </ tr >
202
+ < tr >
203
+ < td > < b > Non-iterator operations</ b > </ td >
204
+ < td > Constant worst-case time</ td >
205
+ < td > Constant amortized time</ td >
206
+ </ tr >
207
+ < tr >
208
+ < td > < b > Iterator constructor</ b > </ td >
209
+ < td > Constant worst-case time</ td >
210
+ < td > linear in current # of items</ td >
211
+ </ tr >
212
+ < tr >
213
+ < td > < b > Other iterator operations</ b > </ td >
214
+ < td > Constant worst-case time</ td >
215
+ < td > Constant worst-case time</ td >
216
+ </ tr >
217
+ < tr >
218
+ < td > < b > Non-iterator memory use</ b > </ td >
219
+ < td > Linear in current # of items</ td >
220
+ < td > Linear in current # of items</ td >
221
+ </ tr >
222
+ < tr >
223
+ < td > < b > Memory per iterator</ b > </ td >
224
+ < td > Constant</ td >
225
+ < td > Linear in current # of items</ td >
226
+ </ tr >
227
+ </ tbody >
228
+ </ table >
229
+ </ p > </ center >
230
+
231
+ < p > </ p > </ li > < li > < b > Decide whether you want to use an array, linked list, or your own class.</ b >
232
+ This choice should be made based on the performance requirements discussed above.
233
+ You may make different choices for
234
+ < tt > Deque</ tt > and < tt > RandomizedQueue</ tt > .
235
+ You might start by considering why a resizing array does not support
236
+ < i > constant worst-case</ i > time operations in a stack.
237
+
238
+ < p > </ p > </ li > < li > < b > Use our example programs as a guide when implementing your methods.</ b >
239
+ There are many new ideas in this programming assignment, including resizing arrays, linked lists, iterators, the
240
+ < i > foreach</ i > keyword, and generics. If you are not familiar with these topics, our example code should make things
241
+ much easier.
242
+ < a href ="http://algs4.cs.princeton.edu/13stacks/ResizingArrayStack.java.html "> ResizingArrayStack.java</ a >
243
+ uses a resizing array;
244
+ < a href ="http://algs4.cs.princeton.edu/13stacks/LinkedStack.java.html "> LinkedStack.java</ a > uses a singly-linked list.
245
+ Both examples use iterators, foreach, and generics.
246
+ <!-- <a href="http://algs4.cs.princeton.edu/13stacks/DoublyLinkedList.java.html">DoublyLinkedList</a> provides an example of
247
+ a linked list where each node has two links, which is useful for being able to go backwards in a linked list.
248
+ -->
249
+
250
+ < p > </ p > </ li > < li >
251
+ < b > We strongly recommend that you develop < a href ="http://en.wikipedia.org/wiki/Unit_testing "> unit tests</ a >
252
+ for your code as soon as you've written enough methods to allow for testing.</ b >
253
+ As an example for < tt > Deque</ tt > , you
254
+ know that if you call < tt > addFirst()</ tt > with the numbers 1 through < em > n</ em > in ascending order, then call
255
+ < tt > removeLast()</ tt > < em > n</ em > times, you should see the numbers 1 through < em > n</ em > in ascending order.
256
+ As soon as you have
257
+ those two methods written, you can write a unit test for these methods. Arguably even better are randomized
258
+ unit tests (which we employ heavily in our correctness testing). We recommend that you create a client class
259
+ with a name like < tt > TestDeque</ tt > , where each unit test is a method in this class. Don't forget to test
260
+ your iterator.
261
+
262
+ </ li > </ ol >
263
+
264
+ < table border ="0 " cellpadding ="2 " cellspacing ="0 " width ="100% ">
265
+ < tbody > < tr align ="left ">
266
+ < td bgcolor ="000000 ">
267
+ < font size ="+0 " face ="helvetica " color ="ffffff ">
268
+ < center > < b > Programming Tricks and Common Pitfalls</ b > </ center >
269
+ </ font > </ td > </ tr > </ tbody > </ table >
270
+ < p >
271
+
272
+ </ p > < ol >
273
+ < p > </ p > < li >
274
+ < b > It is very important that you carefully plan your implementation before you begin.</ b >
275
+ In particular, for each data structure that you're implementing (< tt > RandomizedQueue</ tt > and
276
+ < tt > Deque</ tt > ), you must decide whether to use a linked list, an array, or something else.
277
+ If you make the wrong choice, you will not achieve the performance requirements and
278
+ you will have to abandon your code and start over.
279
+
280
+ < p > </ p > </ li > < li >
281
+ < b > Make sure that your memory use is linear in the current number of items, as opposed to the
282
+ greatest number of items that has ever been in the data structure since its instantiation.</ b >
283
+ If you're using a resizing array, you must resize the array when it becomes sufficiently empty.
284
+ You must also take care to avoid loitering anytime you remove an item.
285
+
286
+ < p > </ p > </ li > < li >
287
+ < b > Make sure to test what happens when your data structures are emptied.</ b > One very common
288
+ bug is for something to go wrong when your data structure goes from non-empty to empty and
289
+ then back to non-empty. Make sure to include this in your tests.
290
+
291
+
292
+ < p > </ p > </ li > < li >
293
+ < b > Make sure to test that multiple iterators can be used simultaneously.</ b >
294
+ You can test this with a nested < i > foreach</ i > loop.
295
+ The iterators should operate independently of one another.
296
+
297
+ < p > </ p > </ li > < li >
298
+ < b > Don't rely on our automated tests for debugging.</ b >
299
+ You don't have access to the source code of our testing suite,
300
+ so the < em > Assessment Details</ em > may be hard to utilize for debugging.
301
+ As suggested above, write your own unit tests; it's good practice.
302
+
303
+ < p > </ p > </ li > < li >
304
+ < b > If you use a linked list, consider using a sentinel node (or nodes).</ b > Sentinel
305
+ nodes can simplify your code and prevent bugs. However, they are not
306
+ required (and we have not provided examples that use sentinel nodes).
307
+
308
+ </ li > </ ol >
309
+
310
+ <!--
311
+ <p><b>When I am asked to give an answer using tilde notation or order-of-growth notation,
312
+ should I include the leading coefficient and the lower order terms?</b>
313
+ By definition, tilde notation includes the leading coefficient but discards the lower order terms;
314
+ order of growth notation discards both the leading coefficient and the lower order terms.
315
+ See pp. 178-179 of the textbook.
316
+ -->
317
+ <!--
318
+ <p><br>
319
+
320
+ <TABLE BORDER = 0 CELLPADDING = 2 CELLSPACING = 0 WIDTH = 100%>
321
+ <tr align = left>
322
+ <td bgcolor = "000000">
323
+ <font size = +0 face = "helvetica" color = "ffffff">
324
+ <center><b>Testing and Submitting</b></center>
325
+ </table>
326
+
327
+
328
+ <!--
329
+ <p><li><b>Getting started.</b>
330
+ Review the code from the textbook for generic stacks and queues
331
+ with iterators.
332
+ You can download the code from
333
+ the
334
+ <a href = "http://algs4.cs.princeton.edu/code">booksite</a>.
335
+ If you adapt our code, you should include a citation to the original source
336
+ from either the textbook or the booksite.
337
+ -->
338
+
339
+
340
+
341
+
342
+ </ body > < div > </ div > </ html >
0 commit comments