Labs

To pass the course, you need to pass the following labs:

Labs account for 1.5 HEC out of the course's total of 7.5 HEC. Note, however, that you are expected to spend significantly more than a single week on lab work.

Lab work should be carried out in groups of two. Exceptions to this rule are granted sparsely and only in exceptional circumstances. The labs must be completed by each group on its own. Copying all or parts of another group's solution or allowing another group to copy yours is considered cheating, and will be dealt with accordingly, so take care to protect your code from prying eyes.

If you are having trouble with a lab, make sure to attend one of the lab supervision sessions. There are (usually) three such sessions per week; see the course timetable for details. To attend a lab session, you will need to book a slot for that particular session. Booking sheets are posted at the bottom floor of Linsen, below the cafeteria. Bookings may be made no more than one week in advance, and each lab group may have at most one simultaneous booking. If you book a slot more than one week in advance or have more than one booked slot at any given time, your booking is considered forfeit and your slot will be given to another group.

Lab submissions are made through the Fire system.

Grading

To pass a lab, you must submit your first attempt at a solution before the first deadline given above. If your first attempt is not accepted, you may submit your lab again before the final deadline. Your initial submission must be a serious attempt at solving the problem at hand, and resubmissions must show genuine improvement over your previous submission.

We use the following system to structure feedback better:

• Comments preceded by "--" refer to an error that lead to the rejection of your lab. It is necessary to fix that before resubmitting. Example:

  -- your file F.java doesn't compile

• Comments preceded by "==" refer to minor errors which you only need to fix if your lab is rejected. Please note that your lab could be rejected even without a "--" error if you have enough "==" comments. If your lab is accepted and you got "==" you don't need to resubmit. Example:

  == your code is not formatted properly and it's harder to read

• Comments preceeded by "**" refer to neutral comments from the grader. They don't need fixing. Example:

  ** your implementation of binary search is slightly non-standard, but it works

• Comments preceded by "++" mean that there is something really good about your submission. Example:

  ++ your implementation of binary search is much better than mine :-)

Labs should be graded within three working days. If your submission takes longer to grade, you may in some cases, upon request, get your final deadline for the lab in question postponed.

At the end of the course, if you have one lab left without a passing grade, you may make a final resubmission no later than 7/1. If you would like to make this resubmission, contact Anton at least one day before the deadline.

Remember, you need to pass all labs in order to get a passing grade for the lab part of the course.

Submission guidelines

Code submissions must be clean, documented and well tested. If you are not sure about what "clean" means, consult any Java style guide; for instance, this one. In particular, clean and documented code:

• is written in English - both comments and code;
• contains documentation for all methods, classes, functions, etc. (preferrably using Javadoc/Haddock), and comments where necessary;
• does not have lines longer than 80 characters;
• uses indentation consistently and sensibly;
• uses spaces rather than tabs for indentation; and
• does not contain any junk (unused code, useless comments, etc.)

• An overview of your code.
• Documentation for classes, methods, functions, etc. as described above.
• Justification that your submission is functionally correct, including a description of how you've tested your submission. Note that "we ran the test program" is not enough: write your own test cases and convince us that they are adequate to ensure that your program is correct.
• Justification that your submission fulfills the required time and space complexity bounds while this does not need to be a formal proof, it should also not be too vague or hand wavy. Examples of too vague arguments include "we used a list as the underlying data structure so our program is linear" and "the task was to implement a heap so it has O(log n) insertions".