Fall Semester 2005: September 8, 2005 - December 12, 2005
Out on:
September 8, 2005
Due by:
September 14, 2005 by 5:59 pm for full credit (11:59 pm for 10% off, hard deadline)
Collaboration:
None
Grading:
Packaging 10%, Style 10%, Performance 10%, Design 20%, Functionality 50%
The first assignment for
600.226: Data Structures
is mostly a warmup exercise.
You will have to (re-)learn the Java language,
including some of the more advanced features like interfaces.
You will get acquainted with a number of Java tools such as
javap and javadoc,
as well as with a number of Unix tools such as
tar and gzip.
Convince us that you're in the right course!
Your first task is to write a simple Java program Numbers
that analyzes the command line it is given in a peculiar way.
The program accepts any number of numbers, counts how often each
number appears, and writes out a prose report about the statistics
it collects this way.
For example, the invocation
java Numbers 0 0 1 0 1 0 0 0 10 1
should generate the output
Among the ten numbers given the number 0 occurs six times, the number 1 occurs three times, and the number 10 occurs once.
Some of the rules for this are as follows: Always print the numbers given on the command line (0, 1, and 10 in this example) as numerals; print numbers you compute (1, 3, 6, and 10 in this example) as words if they fall into the range from 1 to 12 and as numerals otherwise; except for one or two occurances, then print "once" or "twice" as appropriate. Please take note of the way you are supposed to use punctuation marks! Your output should be as close as possible to the output given above.
Please do not use anything aside from basic Java
constructs, strings, and arrays to implement your program.
Specifically, do not use any Java collection
classes!
You can of course use System.out in any way you see
fit to produce your output. :-)
Your second task is to write a number of counters that can be used interchangably (at least as far as Java is concerned). You are given the following interface:
/** The essence of any counter. */
public interface Counter
{
/** Current value of this counter. */
public int value();
/** Increment this counter. */
public void up();
/** Decrement this counter. */
public void down();
}
Develop the following:
ResetableCounter that supports the
message void reset() in addition to those of
Counter; we hope the meaning of this message is
obvious?
BasicCounter that starts at
the value 0 and counts up and down by +1
and -1 respectively.
SquareCounter that starts at
the value 2, counts up by squaring its current
value, and counts down by taking the square root of its
current value (rounding up).
FlexibleCounter that
allows clients to specify a start value as well as an
additive increment (used for counting up) when a counter
is created. For example new FlexibleCounter(-10, 3)
would yield a counter with the current value -10;
after a call to up() its value would be -7.
All of your implementations should be resetable, and each
counter implementation should contain a main
method that tests whether the implementation works as expected.
Finally, develop a seperate program PolyCount
that shows how all your implementations can be used through
a reference of type Counter only; the program
should produce suitable output to illustrate the behavior of the
various counters across the same sequence of operations; you
can define an interesting sequence of operations yourself.
man command is your friend! Use it liberally
while exploring Unix. Try man man for sure!
Interesting information for the bonus problem can be found
with man javap.
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-1-login
with login replaced by your Unix login name
(so I would use cs226-assignment-1-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.
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%.
If you really want to impress us, try the following.
Run javap -c BasicCounter and study the output
produced for your void up() method.
Document each instruction in this method as well as you can in
your README file.
To understand void up() it may or may not be helpful
to look at int value() and void down()
as well.
Note that we won't give you extra points for this, but we'll give
you extra kudos. :-)