Fall Semester 2005: September 8, 2005 - December 12, 2005
Out on:
September 22, 2005
Due by:
September 28, 2005 by 5:59 pm for full credit (11:59 pm for 10% off, hard deadline)
Updated on:
September 24, 2005; I waive the "10% off" time due to the late correction
Collaboration:
None
Grading:
Packaging 10%, Style 10%, Performance 10%, Design 20%, Functionality 50%
The third assignment for
600.226: Data Structures
deals mostly with stacks and queues and their applications.
There are again some "written" problems, to be answered in the
README file.
Your first task for this assignment is to implement a
generic unbounded Stack using a singly-linked list as
outlined in lecture.
Your class ListStack<T> has to implement the
UnboundedStack<T> interface.
To implement the linked list, you should use a
private static final class Node<T>
which holds a next pointer as well
as a pointer to the element stored.
This Node<T> class should be nested
inside your ListStack<T> class!
You should provide a toString() method in addition
to those defined in the UnboundedStack<T> interface.
A new stack on which 1, 2, and 3 were pushed in that order should
print as [3, 2, 1] while an empty stack should print
as [].
Your ListStack<T> class should also have a
main method that performs basic unit testing for
your implementation; be sure to test for all the appropriate
pre-conditions and axioms of the Stack specification (this includes
testing that the appropriate exceptions are thrown in case of a
violated pre-condition).
Here are the necessary interfaces and exception classes,
as well as an implementation of BoundedStack<T>
called ArrayStack<T> that you should study:
stacks.tar.gz
Let us know how you like the code. :-)
Your second task is to implement a basic calculator that
supports integer operands like "1", "12",
and "-45" as well as the integer operators
"+", "-", "*", and
"/" (that's integer division, no fractions).
Your program should be called Calc and work as
follows:
UnboundedStack<T> to hold
intermediate results and then repeatedly accepts input from
the user after printing a prompt "> ".
?" (that's a question mark)
you print the current state of the stack (using the
toString method you implemented in Problem 1).
." (that's a dot)
you pop to top element off the stack and print it.
!" (that's an
exclamation mark) you exit the
program; if the stack is not empty at this point, print it
one last time.
Note that there are a number of error conditions that your
program should deal with gracefully.
For example, if the user enters blah you should
make clear that you don't know what this is supposed to mean
but otherwise continue.
Also, if there are not enough operands on the stack to
perform an operation you should notify the user but leave
the stack unchanged.
All your error messages must start with the symbol
"?" (that's a question mark) on a new line!
Your last task for this assignment is to design the necessary
interfaces and exceptions for queues (both bounded and unbounded).
You should follow the example set by our interfaces for stacks.
You should support the operations empty, enqueue,
dequeue, and front, as well as full
for bounded queues.
Finally, provide an implementation of BoundedQueue<T>
called ArrayQueue<T> that supports all operations in
constant O(1) time.
Once again, you are free to model your implementation after the
ArrayStack<T> class we provided for Problem 1.
Be sure to provide a toString method once again and
to include a main method for unit testing.
In your README discuss the similarities and differences
between the interfaces for stacks and queues that we are using and
those given in the text book.
Take and defend a position regarding which design you prefer.
We won't be hurt if you "diss" ours, as long as you make a good
argument. :-)
Please turn in a
gzip
compressed
tarball
of your assignment (the extension should be .tar.gz).
The tarball should uncompress into a directory
cs226-assignment-3-login
with login replaced by your Unix login name
(so I would use cs226-assignment-3-phf);
uncompressing should not create any other files
in the current directory.
The tarball should contain no derived files whatsoever
(i.e. no .class files, no .html files, etc.),
but allow building all derived files.
Include a README file that briefly explains what your
programs do and contains any other notes you want us to check out
before grading (and of course your answers to "written" problems).
For reference, here is a short explanation of the grading criteria.
Packaging refers to the proper organization of the
stuff you hand in, following the guidelines for Deliverables above.
Style refers to Java programming style, including
things like consistent indentation, appropriate identifiers,
useful comments, suitable javadoc documentation, etc.
Simple, clean, readable code is what you should be aiming for.
Performance refers to how fast your program can
produce the required results compared to other submissions.
Design refers to proper modularization and the
proper choice of algorithms and data structures.
Functionality refers to your programs being
able to do what they should according to the specification
given above; if the specification is ambiguous and you had
to make a certain choice, defend that choice in your
README file.
If your programs cannot be built you will get no points whatsoever.
If your programs cannot be built without warnings using
javac -Xlint
we will take off 10% (except if you document a very good reason).
If your programs fail miserably even once,
i.e. terminate with an exception of any kind,
we will take off 10%.
Develop an algebraic specification for the abstract data type
Queue.
Please use
new,
empty,
enqueue,
dequeue,
and front
as your operations.
Consider unbounded queues only (unless you
want to do a bonus bonus problem, then do bounded queues as
well :-).
The central difficulty is going to be modelling the FIFO
(first-in-first-out) behavior accurately; you'll probably
need to use at least one axiom that performs a case distinction.
Please be advised that doing this problem without
resorting to Google can help a lot on the first midterm...
As always, we won't give you extra points for this, but we'll give
you extra kudos. :-)