Parallel Functional Programming – Programming AssignmentsDAT280 / DIT261, LP4 2017
Home | Schedule | Labs | Lectures | Exam | AboutFire | Forum | TimeEdit | Links
Parallel Functional Programming – Programming AssignmentsDAT280 / DIT261, LP4 2017
Home | Schedule | Labs | Lectures | Exam | AboutFire | Forum | TimeEdit | Links
There are four compulsory programming (lab) assignments in total. You have to pass all of these to get a pass on the course. There are also some optional programming exercises (which we strongly advise you to do). Some labs have extra assignments. These are for your own pleasure; there are no bonus points awarded. You are supposed to work in pairs, so please find a lab partner! Only under highly unusual circumstances do we allow people not to work in pairs. Please contact us in that case. We never allow 3 or more people in a lab group.

It is advisable that both students in a group are at a similar level. Otherwise, there is a risk that the more experienced student will do most of the work, and the other student will not learn much.

If you need to find a lab partner, please use the discussion forum of the course.

Compulsory Labs

Lab A: Parallel Programming in Haskell

Lab B: Sudoku in Erlang

Lab C: Map-reduce in Erlang

Lab D: NESL and Tutorial Writing

Programming exercises (advised but not compulsory)

Lab J: Parallel Functional Programming in Java 8

Lab S: Programming in Single Assignment C

Lab G: GPU programming


The Fire System

All lab assignments must be submitted using an electronic submission system called "Fire".

Remember to register both yourself and your lab partner in your lab group before you submit! By default, the submission system does not accept submissions made by single persons.

The Fire system


Lab Supervision

There are no pre-booked lab slots or supervision. To get help, you should go to the office of one of the TAs, Anton and Markus, at their scheduled office hours (or in extremis at some other time agreed in advance by email).


Deadlines

Each lab (except the first one) has three deadlines.

First deadline:

Final deadline (1 weeks after first deadline):

Submitting after a deadline is in principle unacceptable. It is much better to submit what you have before the deadline, even if you are not happy with it. If you have a good reason for an extension – contact us before the deadline.

If you do miss a deadline, you may get a new chance at the end of the course. Otherwise, there is always a new opportunity to finish the labs next year or at the time of the reexam in August.


Grading feedback

The feedback that you get on your lab submissions may make use of the following symbols:

--    Your function f does not work

Denotes something that has to be corrected and submitted again

==    Your function f is a bit too complicated

Denotes something that has to be corrected only if the lab has to be submitted anyway

**    I see you have solved the problem

Just a regular comment, nothing to correct

++    Your implementation of f is better than mine!

Something extra good, should of course not be corrected


Cheating

Cheating on labs is unacceptable. Cheating means:

On the other hand, it is fully allowed to orally discuss assignments and solutions. The web forum can be used for general and specific questions, but of course not for posting parts of solutions.

If you have problems, you should talk to us instead of copying from others. If needed, you may get more time and more help. If this is not enough, it is advisable to redo the course next year. This option makes much more sense than cheating.

Some cheating can be detected by the lab graders, when they discover similar solutions (e.g. same code, but different comments, layout, variable names, etc.). At the end of the course, we will also use automatic software that checks for similarity between all submitted solutions.

This is what happens if we detect cheating:

But hopefully, this is not going to happen.