D1. Don't plagiarize. The importance of this cannot be overstated. Don't take text or even the structure of the report from colleagues; from wikipedia or online; from papers in the scientific literature; or even from the assignment text itself. It seems many of you consider this type of borrowing to be natural. It is not, and if you do it in a formal scientific public document such as your thesis later on, it can significantly affect your future reputation. Just to make it explicit, if this happens in the final report it's an automatic 0 grade, so be careful.

Examples of this problem in your reports: introductory text taken from the assignment text, from wikipedia, or from one the supplied references. Paragraph-level structure and even formatting (font sizes, etc.) the same across reports, with some sentences copied verbatim.

In case this is not obvious already, the same remark applies to code!

Solution: think up and write your own code and report, with your own structure, style and ideas.

D2. Don't include too many implementation details. Example: the report is just a sequence of code snippets linked together by one or two sentences that only explain what the code is doing. While code can be helpful to reproduce the results it cannot be the main or only point of the document. The code should be given in an appendix anyway, and if it's properly commented it entirely replaces the sequence of code snippets described above.

Solution: Your document should mainly be about the motivations, algorithms and procedures, results, and discussion of the actual problems that you were solving in your assignment, and only secondarily about the implementation. The reader should be able to extract all this independently from the particular Matlab implementation.

D3. Don't include spurious graphics. If the graphic or plot is useful, it should be in a figure with a caption with a number, and it should come with a discussion in the text where the figure is referenced by this number. If you can think of nothing to say about it, then it has no place in the document and should be removed. Example: a hanging validation plot is given without any caption. Or, a screenshot of the fitting tool in Matlab with a caption but never referenced or used in the text.

Solution: Sparingly select what plots to present so that each of them advances the report content-wise. Always explain the purpose of the graphs, discuss them in the text, and reference them by number from there.

D4. Don't make statements unsupported by data. This is a scientific document and anything you say must be supported, either with data in this particular document (your case) or by citations to the relevant literature (probably doesn't apply to this report so much). Examples: "If we increase the number of neurons, after a certain value we don't obtain what we've expected and the performance decreases."  "This is a a pretty good fit."

Solution: Give the data that supports your statement in numerical form (table, graph, or number in the text if it's just a scalar).

D5. Don't be vague or pad your sentences with unnecessary "fluff". Examples: the same as above. What is a "certain value"? What were you expecting? And what does it mean that the fit is pretty good?

Solution: Brevity is the soul of wit, and precision sits at the core of scientific documents. Write economic sentences that make a clear point, without using vague terms. Don't make the text dry, though -- this is a difficult balance that comes with experience.

D6. Don't increase the fonts or add spurious whitespace just to make the report longer. Toner ink and paper are expensive (financially and ecologically), and it is such a transparent "trick" that it can also be insulting to the people who read the document.

Solution: This one should be obvious... Again, brevity and economy are appreciated in science, so if you are sure that your report gives a clear and complete message don't be afraid if it is just a few pages long.

D7. Don't include vague or imprecise math. Any mathematical equation, concept, or procedure must be explained in a self-contained manner such that it is understandable from the document. Example: "We solve linear regression by solving the equation theta = PHI \ Y." This is meaningless without the buildup of the method: it needs an explanation of what is theta, Y, and PHI. Each row of PHI is a regressor vector, so we need to understand the model structure yhat = phi theta, and what is a regressor. And so on.

Solution: Decide carefully on which math is important enough to include in the report, and make sure you explain fully its notation, origin, and reasoning. Instead of vague equations better to not include at all, and explain things at a higher level without the equation.

D8. This one is technical: don't ever identify models (static function or dynamical systems) on validation data! This defeats the entire point of having a validation dataset in the first place, and denotes a fundamental misunderstanding of the core principles of the discipline.

D9. Figures should always axis labels, numbers, and captions, and they should always be references in the text, preferably in increasing order of their numbers.