• Main
• Lectures
• Seminars
• Homework
• Projects
• Tools

Homework

Homework Assignments

The assignments for 2020 will be presented here.

• HW1: Graph Traversal Iterators
• HW2: Binary Heap with Element Modification

Homework Submission

To submit your homework, you are required to use the git repositories created by us on the Faculty of Informatics’ GitLab page under the group pv264/students/2020/YOUR_LOGIN. The repositories will be named hw1 and hw2. To submit the work, you simply tag the commit that contains your final version with a tag that starts with submit. For repeated submissions, simply use different tags that all start with submit, e.g. submit1, submit2, …

Note: If you don’t know how to create a tag in a git repository, you can always use GitLab’s web interface to do so (on the repository page you can click the + symbol above name of the last commit).

You will see the results of your submission in IS, see below for more details.

Repository rules:

• It is recommended that both repositories contain a branch called master and you do all submissions from this branch. (This is the default.) A submitted commit (and its history) may never be changed in any way; this means no force pushes to branches with submits (the master branch is protected by default and cannot be unprotected by you). You can, however, create as many other branches as you wish.
• This also means that once you add a submit tag to a commit, you may not remove it afterwards.
• The repositories are private you are not allowed to change their visibility or members.

Submission rules:

• Once a solution is submitted, an automated submission evaluation system runs it through a set of tests. If all the tests passed, one of the teachers is going to look at your code (see next point). If some of the tests fail, you are provided with a short description of the tests that failed; you have to correct all the bugs and resubmit (see below for submission timing). If you do not submit a solution that passes all the tests before the deadline specified in the assignment, you fail the homework and the course.

• Once your solution has passed all the tests, the teacher has five full workdays to look at your code and provide feedback. If the teacher is not fully satisfied with your code, he will indicate so in the feedback – this means that you have to fix your code and resubmit. If your resubmitted code fails some of the tests, you have to resubmit again as above. The teachers only look at codes that pass all the tests. The teachers will look at your submissions at most three times. If you fail to produce a code with which the teacher is satisfied in your third attempt, you fail the homework and the course.

• The resubmission after teacher feedback may happen after the deadline specified in the assignment (but can happen sooner). However, after each teacher’s feedback, you have one week to resubmit. The resubmission countdown starts on the first midnight after the feedback in inserted into IS. If you do not resubmit within the week, you fail the homework and the course.

• Result timing: First results will appear in IS within tens of minutes after your submission (usually within 10 minutes). These results show that your code compiles on our machine. Sanity checks (basic tests on small inputs) are shown to you once a few hours. Finally, full tests are shown to you once a day. Therefore, regardless of your number of submissions, you can only see one full evaluation a day. This setting is in place to motivate you to write your own tests to test your solutions thoroughly – writing tests is an important part of programming skills.

Compilation on Aisa:

You can check that your code compiles with the recommended compiler on aisa.fi.muni.cz. It has to compile with g++ 10 (module add gcc-10.2) with the following options:

-std=c++20 -Wall -Wextra -Wold-style-cast -Werror -pedantic

We also recommend using clang-tidy. The list of clang-tidy checks we use when checking your code can be found here.

Note: If clang-tidy produces any warnings, we will most probably reject your code. If you think that your code is OK and that the warning is wrong (or unfixable), please write a comment near the problematic part of your code explaining the situation. You may also add a // NOLINT comment on the problematic line to silence the warnings. (This does not stop us from seeing the warnings!) If you don’t understand why a specific warning has been issued, you can always consult the clang-tidy documentation.