CMSC 221: Data Structures

Programming Assignment 5

Description

In this assignment, you are to finish implementing generic unit tests for Map data structures. You are provided four implementations of Map and the unit tests should be designed to ensure their correctness.

Starting code (click here for zip).
Put your name at the top of TestMap.java.

Turn-in list summary

Soft copy (zip) of program to blackboard
Hard copy of only TestMap.java in class.

General Instructions, Turning in assignments, and Grading

General Instructions

Complete every required part of the assignments. Be sure to:
- Name each file and program as listed in the instructions (if there are new files to create), and provide a comment with your name at the top of modified files.
- Comments with TODO define all necessary tasks to complete the assignments. To aid in completion consult the following items:
  - Code documentation. Nice output will be found in Docs. Open index.html in your web browser of choice to see an interactive documentation system. Please note all comments, some tell how the functions should be implemented, what variable names mean, etc.
  - Textbook implementations (note these may not match 100%.
  - Run the program Test.java to run minimal unit tests for the assignment. Note - these tests are minimal, just because they pass does not imply you implemented the functions 100% correctly. It is simply a guideline to help.
- Comments with BONUS define all necessary tasks to complete for up to 10 extra points.
- Program for efficiency (do not have useless instructions) and clarity with a consistent coding style (described more in Grading below)
- Perform experiments as indicated on proper data sizes.
All reports must be typeset using LaTex. Using another program (e.g., Microsoft Word) or handwriting assignments will result in grade of 0. Here is an example homework problem (click here for pdf) worked out to see the expected format and the tex file (click here to see it) that generated it to help you start.
- If you are unfamiliar with LaTex, here is a short tutorial (click here for pdf) and the tex file (click here to see it) that generated it. This tutorial shows how to write common mathematics, how to write pseudocode, how to cite sources, how to include images, and how to include tables.
Follow turn-in instructions precisely.
Failure to complete any of these steps will result in a significant loss of points.

Turn in Instructions

Each assignment will be turned in to both Blackboard (soft copy) and in class (hard copy). Assignments are due BEFORE, let me repeat, before class starts. This does not mean one minute after class starts.

Soft copy (Online submission)
- For programs - create a compressed .zip file of all Java files needed to compile your program and all input files (if needed) to run your program.
  - If you do not know how to create a compressed .zip file, perform a web search (click here) by typing "How to create .zip Windows 10" or "How to create .zip MAC OSX" for example.
- For reports - submit a .pdf file.
Hard copy (In-class submission)
- The first page of your hard copy must be a signed coverpage (click here for pdf).
- Next put the programs (only the ones you wrote code in) in order as described in the description or the report.
  - If you do not know how to print a java file, performs a web search (click here) by typing "How to open and print .java file Windows 10" or "How to open and print .java file MAC OSX" for example. I recommend printing directly from sublime text editor on University computers (has printing feature enabled) and will print with syntax-highlighting (colors). In combination with this, you may have to consult University of Richmond webpages to learn how to use campus printers. If possible, please print 2-sided. Printer issues are not an excuse to turn an assignment in late.
- Staple all pages together.
I reserve the right to assign a 0 to any assignment failing to comply with these instructions. Even for something as small as a missing staple.

Grading

Each assignment is graded out of 100 points (not including bonus).
Expectation and point distribution for programming
- Compiling - If the code is not named precisely or does not compile, up to a 75% deduction.
- Correctness of solution - generating correct output for all imaginable scenarios, up to a 50% deduction.
- Efficiency and stylistic elements of written code, up to a 25% deduction.
Criteria for programming (includes but is not limited to)
- Style
  - Descriptive comments on intent and purpose of code. Do not explain Java to me. The latter will result in deductions.
  - Descriptive and consistent naming conventions
  - Indenting properly (after an opening brace, tab right by 1 indent; after a closing brace, tab left by 1 indent)
  - Consistent spacing
  - Consistent bracket placement (same line or on new line)
  - Avoiding code duplication
- Efficiency
  - Avoid inefficient implementations, e.g., O(n²) vs a better O(n) algorithm.
  - Avoiding useless code statements, e.g., if(boolean-expr) return true; (prefer return boolean-expr;)
- Programming style is important to be able to communicate your solutions to another programmer (e.g., the instructor). A compiling, correct program ≠ 100%, just like a composed paper with the minimum requirements discussed ≠ 100% for an English Writing class.
Expectation and point distribution for reports
- Content of written report, ~80% of the report. Sections and subsections include:
  - Introduction - describe the assignment and your main result in theory and experimentation.
  - Theoretical Analysis
    - Experiment overview - describe what you are testing.
    - Theoretical results - complexities for data structures and relevant operations in accordance to your experiment.
  - Experimental Analysis
    - Experiment setup - describe the hardware and operating system specifications (i.e., processor type and speed, amount of ram, OS, etc.), describe relevant implementation details, and describe range and type of input tested. As a loose guide:
      - O(n²) operations use input sizes of 2¹, 2², ..., 2¹⁶.
      - O(n) or O(1) operations use input sizes of: 2¹, 2², ..., 2²².
      - Main idea - test your computer to the limits of the algorithm to get a good trend. Once the average of the data point exceeds 1/10th of a second you can stop at that data point.
    - Results - describe each plot and figure in full. State the trends noticed and relevant data in text.
    - Discussion - describe the overall importance of the experiment and the major takeaways. Even go as far as to recommend an implementation based on this experiment and different data ranges.
  - Conclusion - summarize the main result.
- Clarity and style of written report, ~20% of the report.
Criteria for reports (includes but is not limited to)
- Use technical writing to provide clear and concise exposition.
- Be sure to only include information that is relevant to the experiment.
- Proper use of LaTeX is also expected. Points will be deducted for not using mathematics mode or LaTeX tables for example.
- Presentation of the plots is critical. Be sure to label all axis, choose appropriate scales (e.g., log scale with appropriate min and max ranges), plot type (e.g., scatter plot with straight lines and markers to denote trends vs scatter plot with polynomial curves), clear legend, etc. Do not have the plot outlined. Text and plot size should be appropriate for the report. Use figure captions in LaTeX instead of plot titles.
- Include a table of Big-oh constants that are calculated. Big-oh constants include n₀ and c.
If there are any discrepancies in grades, please see the instructor during his office hours or by appointment (do not discuss with the lab assistants or graders).