CSC 212 – Data Structures Lecture 20: Deques

Question of the Day How did the clerk know that the man telling the following story is a fraud? I hope you can help me. I'm an English Professor and I find myself in need of help. My wife and oldest daughter went shopping with my wallet which contained my cash and my credit cards and my identification and all that. My other daughter has taken ill in our hotel room. I must buy her some medication immediately, but I have no money. I have a check in my jacket pocket, but I, of course, have no identification. older

Debugging a Program Debug program when not working properly  Could be an error in the code  Program logic could be incorrect  Design may not allow certain features Better to find a bug as early as possible  Easiest to fix when still on paper  Understood best immediately after writing it This is NOT just a programming issue  Debugging is best when starting early

Starting the Program How to start a program 1. Determine what the problem is asking 2. Come up with a good set of tests cases Test cases crucial for working programs  After all, how else can you know it works?  Include a range of different possible inputs  For each input determine the correct output

Test Cases Begin with description of input and output  How else do you know where to start?  How else can you check if you are correct? Break up into different possible outcomes Example: rounding float to nearest int  Positive rounding up  Positive rounding down , 12.1,  Negative rounding down , ,  Negative rounding up , ,  Whole numbers -- 6, -4, 0

Begin to Develop Algorithm Much easier to start on paper  Easier to write, test, and fix Break problem into smaller steps  Each step need not be easy or obvious  Break test cases to test each step  Do not worry solving subproblems yet Use test cases to verify algorithm works  If it does not, go back and fix those problems

Solving Subproblems Solve subproblems separately  Do not worry about larger problem or issues  Can break up into even smaller subproblems  Worry about code only when it is obvious Solving problems in any part of life  Solving large problems is hard  Solving small problems is not

Stack Interface public interface Collection { public int size(); public boolean isEmpty(); } public interface Stack extends Collection { public E top() throws EmptyStackException; public E pop() throws EmptyStackException; public void push(E element); }

Queue Interface public interface Queue extends Collection { public E front() throws EmptyQueueException; public E dequeue() throws EmptyQueueException; public void enqueue(E element); }

Stacks vs. Queues Stacks access data using LIFO order  Last In-First Out  Good for the perpetually late Queues access data in FIFO order  First In-First Out  Resembles how we handle lines

Limitations of these ADTs Need to access both sides of Collection  Transplant waiting lists  Help center phone banks  My Grandpa playing cards Cannot be done with Stack  Can only insert at & access top Cannot be done with Queue  Can only add to end, get element from front

Deque ADT Pronounced “deck”  Avoids mistaking it for dequeue()  Stands for Double Ended QUEue Elements added & removed from front & rear Can be implemented with array or linked list  Really needs doubly-linked list Combines Stack and Queue ADT

Deque Interface public interface Deque extends Collection { public E getFirst() throws EmptyDequeException; public E getLast() throws EmptyDequeException; public E removeFirst() throws EmptyDequeException; public E removeLast() throws EmptyDequeException; public E addFirst(); public E addLast(); }

Your Turn Get back into groups and do activity

Before Next Lecture… Keep up with your reading! Start Week #9 Assignment Work on Programming Assignment #2