Problems

Typically you will encounter one or more unanticipated "problems" in any given exercise. This is not a cause for alarm or dispair. We expect you to encounter problems: you would not have the opportunity to learn anything if you did not. Problems are opportunities for learning - and opportunities for getting marks in your report!

Note that this applies to the Lab exams just as to the normal exercises. We do not expect that you will be able to complete a exam without running into any problems. The central point of the exam is not to see whether you can avoid running into any problems, but whether you can effectively respond to whatever problems do arise.

Some problems will be very minor and will not deserve reporting. For example, you leave out a semi-colon, or mistype a variable name. Provided these are easily and quickly fixed, you should omit them from the report. But, as a rule of thumb, any problem or difficulty which takes up anything in excess of 10 minutes of your time qualifies as significant, and something which must be described in the report.

Remember: you can still get a very respectable mark on a report, even if you make relatively little "progress" in completing the given exercise - provided you can clearly explain what problem(s) you encountered and what steps you took to solve them.

In fact, you will often find that the discipline of trying to explain clearly what your problem actually is often gives you an immediate insight into how to solve it!

Problems are extremely diverse, and it is impossible to give a complete description here; but there are some specific kinds for which we can give more detailed advice.

• Problems of Understanding: For example, "I don't understand what a matrix is", "I don't know what type double means", "I don't understand what for does", "I don't understand what the given program SUPER.C is supposed to do".

  These are all perfectly good statements of a problem. The sorts of steps you can consider in trying to solve them include (re-)reading the relevant section of the textbook, (re-)reading the on-line notes, looking for information in the on-line documentation, trying something in isolation in a small test program to see what happens, asking a colleague, asking a demonstrator.

• Compilation Problems: If messages are thrown up when you attempt to compile a program, then these definitely constitute problems. Some may be trivial, as already discussed; but some may be very difficult, in which case they should be discussed in the report. In that case, you should include, verbatim, at least the first message which is coming up, together with enough of the program file to see the context in which the message is appearing. Strategies for solution include: trying variations in the program to see what effect these have on the message(s); using the on-line documentation to try to get more, or better, information; trying to find a different way of programming whatever it was you wanted to program. And so on.

• Run-time Problems: These are generally of the form "I ran this program, gave it this data, and this (unexpected) thing happened". Note carefully that an adequate description of this kind of problem requires you to say clearly what the "expected" or "correct" behaviour would have been. In fact, it will sometimes turn out that the solution to this kind of problem will be to recognise that you were mistaken in what you expected (i.e. the program is actually behaving "correctly"). In any case, solution strategies for this kind of problem include: rerunning the program with the same data (to see if the symptoms are repeatable); rerunning the program with different data (to see if a pattern of failure can be built up); adding extra code to the program to get more information on what's going wrong; cutting down the program to try to localise the problem. And so on.

• Equipment Problems: You may encounter problems with the lab equipment - hardware or software. These will typically be outside your control to fix. But, if such a problem has impacted significantly on doing the exercise, you should include it in the report. In particular, you should explain what the symptoms were, why you classified it as an equipment problem, and how long it took for it to be sorted out.