Assignments

• Assignment 1 is worth two tokens and is due on 1 February at midnight. The assignment is individual. Here is my solution. The solution uses my my quick and dirty string tokenizer (but you do not have to download it separately, it is included in the solution).

• Assignment 2 is worth two tokens and was due on 16 February at midnight.

  In solving this assignment you are allowed to work in teams of no more than two students. All the collaborators must be named in the README file and must be currently registered in the course. Feel free to supply as many email addresses as you need in the README file (I will send my feedback to all of them). Please submit once per team from the account of one of the team members and please do not resubmit from a different account.

Submission procedure for assignments

Your program must build using reasonably recent versions of GNU make GCC. Anything that does not compile using these tools will be marked as a non-working program. However, a working program does not automatically qualify you for full marks. Bad or missing documentation (sensible comments in the code are part of a good documentation) can incur a penalty as large as 40%. Obfuscated programming can further reduce your mark.

Pay special attention to how you test your program. Incorrect implementations (aka bugs) identified as such may or may not subtract marks, depending on the extent of the problem. Bugs that would have been caught by a complete test suite but have not been identified by you will subtract marks no matter their extent.

Be aware that identical or nearly identical submissions by two (or more) students/teams (as the case misght be) will receive (all of them) an automatic grade of 0 tokens. Further action according to the departmental and university guidelines for academic dishonesty may be pursued.

Presentation and content

The assignments should be handed in electronically, as one directory which in turn contains your work for the given assignment. Do not create any kind of archive; submit the directory itself, unarchived. The name of the submitted directory need not follow any particular format; it will be automatically prefixed by the name of your account at submission time.

Each submission must contain the following:

Your working code.

Should you use code other than yours, proper credit should be given to that code's author. Proper credit to my code (in the case that you are provided with an existing program to modify) means clear identification of your changes, or grouping your changes in a new module. Failing to give proper credit (and getting caught while at it :-)) shall be considered academic dishonesty and will result in an automatic mark of 0 tokens for the given assignment and possibly further action according to the relevant departmental and university guidelines.

A suitable makefile.

Building your code must produce an executable with a precise name (given in each assignment) in the root directory of your submission. The build process must complete successfully when using GNU make and GCC by simply typing make at the shell prompt in the root directory of your submission.

Documentation.

Documentation is an integral part of your submission. Documentation should include:

• A user guide for your program. Document any deviations from, or additions to the API/human interface/protocols (as the case may be) requested in the assignment handout.
• Building instructions. Include here any target of interest in your makefile other than the default one, as well as a list of files and modules together with what they contain and what they implement.
• An overview of what the program does, and how it does what it does. This section shall complement the assignment handout and shall include descriptions (or references thereof) to all the algorithms used by your code which were not given in class or in the assignment handout. Also describe here any non-obvious implementation solution you came up with. If you did some smart coding by all means document your smartness (otherwise I might miss it).
• Suitable comments in the code, outlining the functionality of all the pieces of code and referencing the section on algorithms and functionality (above).
• A description of tests performed and an argument that your test suite is complete. If the tests are easily reproducible, just the description will do. Whenever your tests require special settings which are not easily reproducible, you must include the actual results. ``Not easily reproducible tests'' include those tests which are done by writing extra code (case in which the commented extra code should be included), and/or bulky test input (case in which the input should be included in a separate file). Do not include test output unless you want to make a point based on it (and then include only relevant portions). After reading your test description, I should be able to easily reproduce all your testing and I should become convinced that your test suite is a reasonable proof of correctness for your submission.
• If your program does not work according to the specifications, you must include a detailed description of what debugging you did and why do you think the program still does not work correctly.

The documentation can be included in the README file (see below) if its size does not justify a separate document.

Any document must be submitted in an open (non-proprietary) format. In particular, Microsoft Word or Wordperfect files are not acceptable. The preferred format is plain text, but others are fine, including but not limited to HTML, Postscript, and TEX (L^ATEX included). Good ol' hardcopies are also accepted. :-) Anything submitted as hardcopy should contain on top of the first page the name of all the collaborators.

A README file.

The file should provide a short description of each file in your submission. It must contain the name and student number of the author, and the email you want the marks and comments sent back to. This file must be called README (capitalization and extension, or lack thereof, optional) and must reside in the root directory of your submission.

How to submit

The following submission method is compulsory; assignments submitted in any other way will not be marked. Go to a terminal (in J118 or on the server) and type

submit csc414 dir

where dir is the directory you want to submit. You can specify it by either a relative or an absolute path. Also note the capitalization of ``csc414,'' which must be observed.

Resubmissions

Resubmissions within the due date are allowed. Just re-issue the above command.

Late submissions

Short answer: Your late submission will be accepted (with a penalty) if and only if the submit program does not say otherwise.

Longer answer: Late submissions will incur a penalty of 20% per day. Under no circumstance will a submission be accepted after solutions have been made public. Solutions may be posted as soon as three days after the assignment due date. If the submit program says that submissions are disabled, then your work will not be accepted.

Example

Let's say that your work (code, documentation, etc.) is in the directory ~/csc101/assignment1, and that the current working directory is ~/csc101. You should then type one of the following commands:

    submit csc414 ~/csc101/assignment1
    submit csc414 assignment1
    submit csc414 ./assignment1

Type man submit for more details.

How to test your program

When you test your program, your first priority is to test the behaviour of your code when the input is correct. Ideally, you should take into consideration all the possible inputs. This is usually impossible, but at least I want to see from you a genuine effort in this direction.

In order to test the program on correct input, you should identify to the best of your ability classes of input, i.e., categories of input for which your program should behave in a different manner. Once these classes are identified, you could pick one (or more) sample inputs from each class and feed them to the program.

Of course, the reaction of your program to erroneous input should be considered as well, but that should be your secondary goal during testing. Unless otherwise stated in the handout, just a notice of unexpected results for incorrect input will do (whereas testing correct input may require debugging). One notable exception is buffer overflows, which should be as much as possible avoided.

I am not asking you to do a perfect testing suite, I just ask for a honest effort on the matter. I also ask for a brief explanation of why is your test suite complete, just to make sure that you knew what you were doing.

Poor test suites or poor explanations will be penalized, especially when your program exhibits an erroneous behaviour that would have been caught by a reasonable set of tests.