Assignments

• The first assignment is worth two tokens and was due Friday, 29 January at midnight. Here is my solution.

• The second assignment is worth four tokens and was due Thursday, 18 February at midnight. Your solution to this assignment started from the btree module contained in the implementation of binary trees presented in class. Here is my solution.

• The third assignment is worth four tokens and is due on 17 March at midnight.

How to test your program

It is expected that you do reasonable testing on your program and that you describe these tests in your submission.

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 differently. Once these classes are identified, you could pick one (or more) sample inputs from each class and feed them to the program.

Pay attention to boundary cases, these are often overlooked in the programming process.

Of course, the reaction of your program to errorneous 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 array overflow, 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 errorneous behaviour that would have been caught by a reasonable set of tests.

Submission procedure for assignments

Your program must build using reasonably new versions of GNU make and GCC, and with the flags -ansi and -pedantic (this ensures that you use standard C++). Anything that does not compile under this condition will be marked as a non-working program.

A working program does not automatically qualify you for full marks. Bad, obfuscated programming can subtract as much as 50% of your mark. Bad or missing documentation (sensible comments in the code are part of a good documentation) can also incur a penalty as large as 40%.

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) teams will receive (all of them) an automatic mark of 0 tokens. Further action according to the departmental and university guidlines 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 guidlines.

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.

Your makefile must contain a macrodefinition of CFLAGS and every compilation process must use this macrodefinition.

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 (as the case may be) requested in the assignment handout.
• Building instructions. Include here any target of interest in your makefile, 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.

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. In must contain the name and student number of all the collaborators, and the email(s) 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 two submission methods are compulsory; assignments submitted in any other way will not be marked.

1. Go to a terminal (in J118 or on the server) and type

   submit csc218 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 ``csc218,'' which must be respected.

2. Rename the directory to be submitted by prefixing it with the name if your J118 account followed by a dash, archive the into a TAR or ZIP archive (make sure that the directory structure is kept, and please do not use other archive formats), and send the result to me as an email attachment. Please use the name of your directory as the subject of your email.

Resubmissions

Resubmissions within the due date are allowed. Just re-issue the above command (or send another email).

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 ~/csc497/assignment1, and that the current working directory is ~/csc497. You should then type one of the following commands:

    submit csc218 ~/csc497/assignment1
    submit csc218 assignment1
    submit csc218 ./assignment1

Type man submit for more details.