Assignments

This assignment is worth 10% of your final grade for COSC201. It consists of a coding section (5 points), and a report (5 points). The coding assignment is to complete the implementation of the code given in the cosc201 assignment 1 repository.

The university guidelines for late submission will be followed. These amount to a reduction in the grade by 5% of the total mark available per day (or part thereof) late, up to a maximum late period of seven days. If extensions are needed these should, if at all possible, be requested and arranged in advance.

The code should be submitted via git. The report should be submitted as a pdf via Blackboard.

This assignment is worth 10% of your final grade for COSC201. It consists of a coding section (5 points), and a report (5 points). Some code will be provided in the cosc201 assignment 2 repository.

The university guidelines for late submission will be followed. These amount to a reduction in the grade by 5% of the total mark available per day (or part thereof) late, up to a maximum late period of seven days. If extensions are needed these should, if at all possible, be requested and arranged in advance.

The code should be submitted via git. The report should be submitted as a pdf via Blackboard.

Many reports from previous years suffered from the same set of limitations, so you might want to take into account some of the most frequent comments regarding reports below:

A sentence or two of introduction to the report as a whole would be good here.

This generally came right at the beginning of any reports which dove straight into an analysis of the experiments in the first part, without any background whatsoever. A somewhat related issue arose frequently in the first part when a report would talk about an “experiment” or a “run” or a “trial” without first telling the reader what that actually was.

Generally speaking it’s a help to the reader if normal text, references to code, and references to mathematical concepts are immediately distinguishable from one another. The most common way to do this is to use a mono-width font for references to code and italics for the maths.

This was used in places where there was a mixture of references to code, e.g., method names or class names like union or BaseSimulator together with mathematical concepts, e.g., O(n), and normal text. It really is much easier for fluent reading if these are typographically distinguishable.

This kind of analysis can be a good starting point but it’s important to remember that it’s the worst-case time-complexity of the various operations that’s usually considered in the theoretical discussions of them. So, at the very least, one needs to be careful about words like “expected”.

This was used when the report seemed to lean too heavily on the analyses we’d done of the time-complexity of the various union-find implementations. As noted, it’s very important that these are largely worst-case analysis, and the point of the experiments in the report is really to figure out how these implementations differ in a particular context. We can’t draw any general conclusions from that (since the conditions in some other context might be different) but it’s important to recognise that absolute worst-case is frequently not the right criterion to be making a choice on.

The jaggedness of the curves is suggestive of more variation in the results than are being smoothed out by the number of trials. It would have been better to carry out more trials per size across a more widely spaced range of sizes - after all there is very little reason to expect any sharp change in behaviour for a small change in the size.

Something like this arose typically when experiments sampled values very closely, e.g., every possible side length for a base in a range, without averaging results. It’s almost always better, if you have only a limited amount of time available to collect data, to prefer repetitions over density of sampling.

Exponential growth means “the value measured increases by a fixed factor when we increase the controlling parameter by a fixed amount”, not just “the value measured increases at more than a linear rate”. True exponential curves, once they start to bend at all generally bend very sharply leading to the traditional “hockey stick” shape: ____/

One of Michael’s pet peeves (lecturer in previous years). He’s given up the fight on the use of exponential growth as a phrase to mean “anything greater than linear growth” in common language, but in formal writing (and particularly in any reasonably mathematical concept) it’s still important to maintain the distinction. Exponential growth has a specific technical meaning in technical writing, and you should use it in that sense.

In a report of this type a graph is almost always better than a table. In my opinion, the only reason to include a table of actual values is if you have a reasonable expectation that the reader will want to make use of those actual values.

This is pretty self-explanatory. For comparison purposes some sort of chart or graph is almost always more useful and more attractive than a table of values.

• 2022 Assignment 1 and an overly long version of its report
• 2023 Assignment 1 and an overly long version of its report

The reports above were written by Michael after the fact. They are longer than would be allowed for this year’s report but in the way they’re presented they show one way to produce an excellent report. However, there were many reports that got 10 out of 10 (or close to it) that were presented in a different style – so long as it is clear, and addresses the issues in the assignment, the exact format is up to you.