Lab assignments

Here you find the lab assignments.

Setup

The course contains four lab assignments. Each lab assignment contains a set of tasks. The goal of the lab assignments is that you should develop a reusable code library, with implementations of useful algorithms and data structures. The labs are not mandatory, but there are two good reasons to do them anyway: they give grade points, and they can be useful during the problem sessions and for the homework problems.

Each lab assignment can give up to 9 grade points on the LAB1 moment. The labs can be done in groups of up to two people. Labs solved after deadline do not give any points.

Evaluation of lab assignments

The evaluation of your lab assignments consists of two parts:

Automatic testing by Kattis. For each lab assignments there is a corresponding Kattis task where she will verify that you have solved the lab assignment correctly.
A subjective assessment of the quality of your code. You will present your code to us and demonstrate that it is well documented and structured (see also Code requirements below).

Presentation

You present your solutions orally, roughly 15 minutes per group. In connection with the deadline, an e-mail will be sent out letting you book a presentation slot.

Within a day after deadline (or before, if you are ready ahead of time), every group must send an e-mail to popup-15@csc.kth.se containing the following:

Subject/ärende: "[popup15] Labb X", where X is the number of the lab assignment (1 to 4).
List of who (up to two people) are part of the group.
List of which problems have been solved, as well as link to the accepted Kattis submission for each problem.

Deadlines

Deadline for each lab is the evening before the corresponding problem session. See the schedule för precise dates and times.

Code requirements

General requirements

The code must be well commented and nicely structured. For every assignment, we give suggestions for an API of the function/klass to be implemented. These suggestions do not have to be followed mindlessly, if you think it is nicer to do things some other way then that is fine, as long as the function still solves the task at hand. You might want to read the GNU coding standards and/or Google coding standards for inspiration, but use your common sense.

Authors

The name of the author(s) must be listed in a comment at the top of each file.

Documentation

The purpose and API of each function and class must be documented with comments in the code.

Error handling

Ideally, it would of course be nice if your algorithms and data structures were completely robust and general, but this can be difficult. Exceptional cases must be handled in some way, for instance by throwing exceptions, or at least by properly documenting any assumptions that are made on the input.

Mer specific requirements

Here are some interpretations, applications, and rules of thumb relating to the requirements. They are not an exhaustive list of what is needed.

The code must be general and not have hard-coded constants related to the size limits in Kattis: if the sizes in the Kattis problem are increased, your solution should be able to handle this without having to change anything in the code (at least within reason). It is OK to make assumptions about how large an integer type is needed to represent the answer, but it is NOT OK to e.g. assume that a string is at most 5000 characters long just because that happens to be the case in the Kattis problem.
Global variables can be a simple solution that works well when solving homework problems and problem session problems. But they are inappropriate for library code that is meant to be reused. Avoid global variables.
Separate functionality from I/O. Read input, send it to the solver, receive solution, and then format this according to the specific output format of the Kattis problem. Don't let the generic algorithm be responsible for input and output. The algorithm should not be tailored to the Kattis tests in any way.
Make sure to separate the code into files appropriately. Do not cut and paste Kattio.java into your own file, keep it separate!
Too many comments. Most of the time, single lines are reasonably self-explanatory and comments along the lines of
// read input to buffer
are almost always superfluous. Do not comment single lines but write comments describing the logic and purpose of entire functions or blocks of code within a function.
Document the API for central functions so that it is clear what input and output values are. Write the documentation primarily for someone wanting to use the code, as opposed to someone wanting to edit the code.
The lab tasks give suggestions for an API. Use it if you don't find something which is at least as good (with respect to reusability). The API must not be tailored to the Kattis tests.
List author(s) at the top of all files, including header files and early submissions.