Individual Projects and Talks

Please read this document in its entirety. Pay particular attention to the advice on citation and references and avoidance of plagiarism.

Read the instructions on submission on the project description page.

Written report

Requirements

• The page limit is three sides of A4. This is interpreted strictly and includes everything except references. Anything over the limit is ignored by markers.
• You should use LaTeX and do so correctly without "hacking". (This means that you should use e.g. LaTeX sectioning commands, list environments, etc rather than creating your own headings and lists by forcing line breaks, spacing and font sizes.)
• You may use either document class "article" or "amsart" - in either case with "[11pt,a4paper]" - this is all in the very first line of your .tex file. Do not alter the page-size, font, style, etc. You will lose marks if you generate headings, paragraph breaks, etc, by means other than the standard LaTeX commands.

Hints

• Your project should be readable by a mathematician who has not seen the project description.
• Explanation of how your Maple procedures work should mainly be confined to your Maple Worksheet.
• Your report should be mainly on your own results obtained with Maple, except where a part of the project particularly asks you to do some research and report on the mathematical background, or similar. Some additional background material is welcome, but it should not become the main subject of the report.

MATLAB

Requirements

• The submitted worksheet should  contain no lines of output. (Remove the output before submitting and make sure the M-file runs smoothly, producing figures and whatever output the grader is supposed to see.)
• The worksheet should produce all the results that you wish when it is executed from start to finish. Give the M-file a suitable name, like the first 5 letters of your family name and then .m !
•  

If a command takes a long time to run (greater than 20 secs or so), then comment it out (put a % in fromt) and invite the marker to run it if they wish.

Hints

• Document your worksheet, but don't overdo it. Add some text to explain briefly what your procedures do and add some comments to your code where its function is not obvious.
• Indent procedures, loops, etc.
• Where appropriate and possible, make sure your procedures are tested. Consider what cases might be slightly different or unusual and check your procedure works on them if possible.

Talks

Requirements

• Your talk should last 10 minutes.
• Written materials: We recommend using the overhead projector, but you may use the blackboard or a combination of the two.
• It is not possible to have a "live" computer for your talk. Thus you can not use powerpoint for your presentation or give live MATLAB demonstrations.

Hints

• Practice it before-hand to get the timing right and so that you can give it without continually refering to notes. You are required to attend the whole session of talks in which yours is given.
• You should aim the talk at fellow students in the audience who may not have studied your project. Make sure your talk is accessible to them. Do not skimp on describing the problem and its background.
• 10 minutes is not very long. You will need to be selective about what you say. The important thing is that the talk stands on its own as a presentation - it does not have to cover "everything" that you did. Some things you may like to cover in addition to just showing some results are: did you achieve everything you hoped to; what might you have done with more time; are there cases your procedures do not work for; were there any particular difficulties.
• Do not have too many transparencies - six or seven is probably enough. Transparencies should be clearly visible from a distance. If you prepare them with LaTeX use document class "slides" - ordinary typeset pages have far too small a font. It is fine to hand-write transparencies too. You can annotate printed sections with coloured pens to draw attention to important points.
• It is not easy for audiences to take in large chunks of Maple code. A flow chart is better for explaining the logic of your procedures. If you are showing some Maple (results, or perhaps an important piece of code) then make sure you zoom in so that the font size on your transparency is large enough.
• Listen to other students' presentations and contribute to the discussion after each. You will help each other by being an attentive and interested audience.
• Think what the main points you want to explain are and stick to them. If your talk is in danger of being too long, consider whether points can be just mentioned or even omitted rather than being discussed in detail.
• You should write notes for what you intend to say, perhaps just key points, perhaps some more detail. But you should try and have it sufficiently firmly in your mind that when you give the talk you need refer to your notes only occasionally. Your overheads should keep you on track.
• Don't get bogged down in detail: it would be quite hard to discuss in complete detail what a procedure with a dozen lines is doing even if you devoted the entire talk to it.
• Don't cram transparencies full of information - it is no good if people don't have time to read and think about it. You can highlight aspects of Maple worksheets by writing on the transparency with coloured pens.
• Try to stay calm and relaxed. (This is easier said than done, but there should not be too much to worry about if you have rehearsed properly.) Don't rush your presentation. If you get in a muddle on a point, pass on rather than waste a long time sorting it out. Present your material positively and confidently. Speak up, and speak to your audience, not to the furniture. Decide where you will stand in relation to the overhead projector so that you will not block the audience's view.

Citation, References and Plagiarism

In academic work, acknowledging carefully the extent to which your work depends on others' is of the utmost importance. Failure to do this is plagiarism, which is a University offence.

• Direct quotations (or quotations with only minor changes) must be clearly identified as such and a reference given. Such things should only ever be short - obviously there is no credit available for including large segments of other peoples' labour, and that includes wikipedia.
• If your line of argument or background results that you are using owes something to a source (whether lectures, a book, a fellow student or a web-page) then you should give a citation and reference.
• It should always be clear what part of your work you are deriving from your source. Sometimes a reference can be fairly general. It is OK for example to say: "Our treatment of the background material is derived from [1] and [2]." But otherwise citations should be quite particular. For example: "Figure 2 is taken from [1]" or "the general result of which this is an example can be found in [3,page 200]".
• It is not enough just to put a reference at the end of your work. Each reference should be cited in the text at the relevant point.
• Use the LaTeX bibliography, cite and ref commands for your citations and references.
• These rules apply also to talks (where such acknowledgments would usually just be verbal) and to Maple (so that if your code owes something to others work or was given as part of the project description, you should make that clear in the worksheet).
• The only exception to the rules above (and this applies only to the group projects) is that you need not quote/reference other members of your group.

Marking

·  The mark-scheme for projects is on the web. You are advised to study it.

·  The mark-scheme for talks is on the web. You are advised to study it.

·  The written report and Maple code of the group project will count for 35% of the total course mark. The group talk will count for 15% of the total course mark.