## Assignment sets

Each block comes with a set of 6 assignments which constitute a
significant chunk of available points. You can make up to 12
attempts at passing verity tests on each assignment, evenly
distributed throughout a 4-week period. Submissions will open at
0:00 of the first day of this period (24h before first verity run).

Submission deadlines (evaluation of verity tests) take place every
Monday, Wednesday and Friday at 23:59, according to the following
schedule:

│ set │ week │   Mon   │   Wed   │   Fri   │
├─────│──────│────────▻┼────────▻┼────────▻┼
│   1 │    1 │  25.9.  │  27.9.  │  29.9.  │
│     │    2 │   2.10. │   4.10. │   6.10. │
│     │    3 │   9.10. │  11.10. │  13.10. │
│     │    4 │  16.10. │  18.10. │  20.10. │
│┄┄┄┄┄│┄┄┄┄┄┄│┄┄┄┄┄┄┄┄┄│┄┄┄┄┄┄┄┄┄│┄┄┄┄┄┄┄┄┄│
│   2 │    1 │  23.10. │  25.10. │  27.10. │
│     │    2 │  30.10. │   1.11. │   3.11. │
│     │    3 │   6.11. │   8.11. │  10.11. │
│     │    4 │  13.11. │  15.11. │  17.11. │
│┄┄┄┄┄│┄┄┄┄┄┄│┄┄┄┄┄┄┄┄┄│┄┄┄┄┄┄┄┄┄│┄┄┄┄┄┄┄┄┄│
│   3 │    1 │  20.11. │  22.11. │  24.11. │
│     │    2 │  27.11. │  29.11. │   1.12. │
│     │    3 │   4.12. │   6.12. │   8.12. │
│     │    4 │  11.12. │  13.12. │  15.12. │

### Submitting

Each assignment comes with a single source file (the skeleton). You
should write your solution into this file and then submit it, the
same as with practice exercises:

 1. using «homework vault» ‹sN_name› in the ISu (e.g. ‹s1_a_life›),
 2. by running the command ‹pv264 submit sN_name› in ‹~/pv264/sN›,
    e.g. ‹pv264 submit s1_a_life›.

More detailed instructions can be again found in Chapter T.

### Evaluation

The evaluation of your submissions is split into three phases, each
with its own set of tests:

 • „syntax“ – checks that the submitted program is syntactically
   correct, can be compiled and passes basic static checks,
 • „sanity“ – ensures that submitted programs behave reasonably on
   simple inputs – these tests are similar, in their style and
   extent, to the tests bundled with other types of exercises,
 • „verity“ – thoroughly checks correctness of the solution,
   including complex inputs, edge cases, and memory errors.

The phases are interdependent – if you fail one of them, the
subsequent phases won't even run (for a given submission, of
course). The key phase is the last one, verity, which you need to
pass in order to get any points at all. The timing of the phases is
as follows:

 • syntax is checked immediately (within 5 or so minutes of the
   submission),
 • sanity is checked every 6 hours aligned to midnight (i.e. 0:00,
   6:00, 12:00, 18:00),
 • verity is checked on Monday, Wednesday and Friday at 23:59
   (see the table above).

Only the latest submission is evaluated and each submission is
evaluated at most once in each phase. The results are, as always, in
the notepad in the IS (each assignment in a separate pad). You can
also get them by running ‹pv264 status›.

### Grading

Each assignment which passes verity (within the given deadline, of
course) counts for 10 points.

For a given successful assignment, you can additionally obtain up to
5 points for writing your code well. These points are counted in the
block during which they have been awarded, i.e. points from reviews
of «set 1» count toward «block 2».

The maximal proceeds per set:

 • set 1: 60 for correctness in block 1 + 30 for review in block 2,
 • set 2: 60 for correctness in block 2 + 30 for review in block 3,
 • set 3: 60 for correctness in block 3 + 30 for review in block 4
   (in the «exam period»).

### Code Quality

Automatic tests check the «correctness» of your programs (within the
limits of practicality – even the strictest tests cannot guarantee
that your program is completely correct). Correctness is, however,
not the only criterion for evaluating programs: it is just as
important that programs are «readable». Programs, among other
things, serve to communicate ideas to other people – well written
and adequately commented code should tell the reader what problem it
solves, how does the solution work and on both counts, «why».

It is hopefully clear that human-readability of a program can only
be assessed by a human: for this reason, each «successfully» solved
assignment will be subject to a review. This review will include a
grade, according to criteria laid out in Chapter Z. When grading,
this is how we apply the criteria:

 • a solution will be graded A if it clearly describes a solution of
   the stated problem, is correctly decomposed, is coded without
   avoidable repetition using appropriate abstraction, algorithms
   and data structures,
   
 • grade B will be given to programs with significant shortcomings
   in one, or non-negligible shortcomings in two of the areas
   mentioned above, e.g.:
   
   ◦ the program is correctly decomposed and does not repeat itself,
     but uses an unsuitable algorithm or data structure and is
     sometimes hard to follow,
   
   ◦ uses an optimal algorithm and data structures, and is correctly
     decomposed, but locally repeats the same code with minor
     variations and sometimes uses misleading or incorrect
     subroutine names, variables, etc.,
   
   ◦ otherwise good program which uses a very bad algorithm, «or»
     very poorly named variables «or» is a big monolithic blob of
     code with no decomposition whatsoever.
   
 • a program will be graded X if you clearly state that you do not
   want the program reviewed (in a comment «at the top of the file»,
   e.g. ‘Please do not review.’),
   
 • grade C will be given to all other programs, especially those
   that combine two or more substantial failings detailed above.

You will get reviews (and grades) the second Tuesday of the next
block. If you are graded B or C, you may resubmit an improved
solution to improve that grade:

 • you have a week to do this,
 • the improved program must not fail verity tests,
 • verity tests run with the same cadence as always, i.e. Monday,
   Wednesday and Friday at 23:59.

If the reviewer is happy with your improved program, they will
update your grade.

│  set │ regular sub. │  grade │ resubmission │  grade │
├──────│─────────────▻│───────▻│─────────────▻│───────▻│
│    1 │     «20.10.» │ 31.10. │      «7.11.» │ 14.11. │
│    2 │     «17.11.» │ 28.11. │      «5.12.» │ 12.12. │
│    3 │     «15.12.» │   2.1. │       «9.1.» │  16.1. │

Each «final» grade will be rewarded according to this scale:

 • grade «A» carries a reward of «5 points»,
 • grade «B» is worth «2 points»,
 • grade «X» is neutral (no points),
 • grade «C» incurs a 1 point «penalty» (i.e. -1 point).

Points awarded for correctness (based on verity tests) are not
affected by reviews in any way.

### Neúspěšná řešení

Příklady, které se Vám nepodaří vyřešit kompletně (tzn. tak, aby na
nich uspěla kontrola „verity“) nebudeme hodnotit. Nicméně může
nastat situace, kdy byste potřebovali na „téměř hotové“ řešení
zpětnou vazbu, např. proto, že se Vám nepodařilo zjistit, proč
nefunguje.

Taková řešení můžou být předmětem společné analýzy ve cvičení,
v podobném duchu jako probíhá rozprava kolem odevzdaných příprav
(samozřejmě až poté, co pro danou sadu skončí odevzdávání). Máte-li
zájem takto rozebrat své řešení, domluvte se, ideálně s předstihem,
se svým cvičícím. To, že jste autorem, zůstává mezi cvičícím a Vámi
– Vaši spolužáci to nemusí vědět (ke kódu se samozřejmě můžete
v rámci debaty přihlásit, uznáte-li to za vhodné). Stejná pravidla
platí také pro nedořešené přípravy (musíte je ale odevzdat).

Tento mechanismus je omezen prostorem ve cvičení – nemůžeme zaručit,
že v případě velkého zájmu dojde na všechny (v takovém případě
cvičící vybere ta řešení, která bude považovat za přínosnější pro
skupinu – je tedy možné, že i když se na Vaše konkrétní řešení
nedostane, budete ve cvičení analyzovat podobný problém v řešení
někoho jiného).
