-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
* Add file for packages in preamble * Remove list of tables and figures from interim * Include all chapters of interim * Put abstract in separate file * Reorganise the main interim report * Create final report document * Add comments for chapters of final report * Combine references * Move background include to own interim file * Move interim ethical issues to own file * Move interim introduction to own file * Fix input of ethical issues in interim * Add final report to makefile
- Loading branch information
Showing
24 changed files
with
238 additions
and
71 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,4 +1,4 @@ | ||
documents = interim.pdf | ||
documents = interim.pdf final.pdf | ||
|
||
.PHONY: all clean cleanaux spell | ||
|
||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,82 @@ | ||
\documentclass[a4paper, twoside]{report} | ||
|
||
\input{report/packages.tex} | ||
|
||
\title{A Deeper Dive into Relational Algebra by Way of Adjunctions} | ||
\author{Matteo Bongiovanni} | ||
\date{January 2023} | ||
\supervisor{Dr.\ Nicolas Wu} | ||
\secondmarker{Dr.\ Steffen van Bakel} | ||
\documenttype{MEng Individual Project} | ||
\university{Imperial College London} | ||
\department{Department of Computing} | ||
\degree{Joint Mathematics and Computing} | ||
|
||
\begin{document} | ||
\begin{comment} | ||
General Information | ||
The project report (occasionally referred to as a thesis) is an extremely important aspect of the project. It serves to show what you have achieved and should demonstrate that: | ||
|
||
You understand the wider context of computing by relating your choice of project, and the approach you take, to existing products or research. | ||
You can apply the theoretical and practical techniques taught in the course to the problem you are addressing and that you understand their relevance to the wider world of computing. | ||
You are capable of objectively criticising your own work and making constructive suggestions for improvements or further work based on your experiences so far. | ||
As a computing professional, you operate ethically and can explain your thinking and working processes clearly and concisely to third parties who may not be experts in the field in which you are working. | ||
Most of the project assessors will not have followed the project throughout and will only have a short time to listen to a presentation or see a demonstration. For this reason they will rely heavily on the report to judge the project. | ||
|
||
Many students underestimate the importance of the report and make the mistake of thinking that top marks can be achieved simply for producing a good product. This is fundamentally not the case and many projects have been graded well below their potential because of an indifferent or poor write-up. In order to get the balance right you should consider that the aim of the project is to produce a good report and that software, hardware, theory etc. that you developed during the project are merely a means to this end. Don't make the mistake of leaving the write-up to the last minute. Ideally you should produce the bulk of the report as you go along and use the last week or two to bring it together into a coherent document. | ||
|
||
It is helpful to get feedback from your supervisor about your project report, but supervisors cannot be expected to look at documents written at the last minute or at more than one chapter at a time. Allow plenty of time for this. | ||
|
||
Project Report Length | ||
The nominal maximum report length is 60 pages, plus appendices. Shorter reports may be appropriate for many projects and longer reports can be submitted with prior approval (see below). | ||
|
||
The page count includes: | ||
|
||
title page | ||
abstract | ||
dedications | ||
table of contents | ||
The page count does not include: | ||
|
||
bibliography | ||
appendices (but the report should make sense without the appendices) | ||
When writing up your work be reminded of the fact that a 60-page report isn't necessarily better than a 30-page report, in the same way that a 10,000 line implementation isn't necessarily better 5,000 line one. Conciseness, clarity and elegance are invaluable qualities in report writing, just as they are in programming. Indeed, you will lose credit if it is evident to the assessors that the report has been padded with superfluous content in order to make it appear more substantial than the work justifies. The assessors greatly value quality over quantity. | ||
|
||
It is important to understand that the report is assessed on the quality of the technical writing. Here this means your ability to document your ideas, design, implementation, evaluation, conclusions etc. succinctly, using appropriate scientific language, as might a researcher when writing up their findings in an technical magazine, academic journal or conference proceedings. | ||
|
||
If you have good reason to use more than 60 pages you should consult your supervisor and second marker and obtain their approval in advance - they will be required to read and assess the whole report, whereas other assessment team members may only scan key sections. | ||
|
||
Project Layout | ||
The physical layout and formatting of the report is also important. A tidy, well laid out and consistently formatted document makes for easier reading and is suggestive of a careful and professional attitude towards its preparation. Both LaTeX and MS Word will allow you to produce a cleanly formatted document. Many supervisors will advise you to use LaTeX as this solves most of the formatting problems for you. If your report is to contain a substantial number of mathematical formulae you are strongly advised to use LaTeX. | ||
|
||
Project Report Structure | ||
The exact structure of your project (the chapter titles etc) is up to you. Discuss with your supervisor what structure works best for your project. | ||
|
||
A project report will usually contain a number of chapters (Chapter 1, Chapter 2 etc). Each chapter contains Sections (2.1, 2.2 etc) and may also contain subsections (2.1.1, 2.1.2) etc. Try to avoid too many levels of subheading - three is usually sufficient. | ||
|
||
Projects will usually contain all of the following elements, although these may not exactly map to chapters. | ||
\end{comment} | ||
|
||
% Front matter | ||
\include{report/title/title} | ||
\include{report/title/abstract} | ||
\begin{comment} | ||
Table of contents: | ||
This should list the main chapters, sections and subsections of your report. Choose self-explanatory chapter and section titles and use double spacing for clarity. If possible you should include page numbers indicating where each chapter/section begins. | ||
\end{comment} | ||
\tableofcontents | ||
|
||
% Main matter | ||
\include{report/introduction/final} | ||
\include{report/background/final} | ||
\include{report/project/project} | ||
\include{report/evaluation/evaluation} | ||
\include{report/ethics/final} | ||
\include{report/conclusion/conclusion} | ||
|
||
% Back matter | ||
\bibliographystyle{unsrtnat} | ||
% DoC uses the Vancouver Referencing Format. | ||
\bibliography{report/bibs/combined} | ||
|
||
\end{document} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,5 @@ | ||
\begin{comment} | ||
The appendices contain information which is peripheral to the main body of the report. Information typically included are things like parts of the code, tables, proofs, test cases or any other material which would break up the theme of the text if it appeared in the main body of the text. | ||
|
||
Label these as Appendix A, Appendix B etc and refer to the appropriate appendix from the main body of the report. | ||
\end{comment} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,12 @@ | ||
\begin{comment} | ||
User Guide Appendix | ||
It is not common to provide a user guide in the report. This can be included in the repo you submit for the software archive. | ||
|
||
If you do feel that you should supply a user guide (e.g. for projects which result in a new piece of software), you might choose to provide a user guide providing easily understood instructions on how to use it. | ||
|
||
A particularly useful approach is to treat the user guide as a walk-through of a typical session, or set of sessions, which collectively display all the features of your system. | ||
|
||
Technical details of how the package works should be in the body of the report. Keep this concise and simple. | ||
|
||
The use of diagrams illustrating the package in action prove particularly helpful. | ||
\end{comment} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,17 @@ | ||
\chapter{Background} | ||
\begin{comment} | ||
The background section of the report should set the project into context by relating it to existing published work which you read at the start of the project when your approach and methods were being considered. There are usually many ways of solving a given problem, and you shouldn't just pick one at random. Describe and evaluate as many alternative approaches as possible. The published work may be in the form of research papers found in the academic literature, articles, text books, technical manuals, or even existing software or hardware of which you have had hands-on experience. Your must acknowledge the sources of your inspiration. You are expected to have seen and thought about other people's ideas; your contribution will be putting them into practice in some other context. However, avoid plagiarism: if you take another person's work as your own and do not cite your sources of information/inspiration you are being dishonest. When referring to other pieces of work, cite the sources where they are referred to or used, rather than just listing them at the end. Accidental plagiarism or not knowing how to cite and reference is not a valid reason for plagiarism. Make sure you read and digest the Department's plagiarism document . | ||
|
||
In writing the Background chapter you must demonstrate your ability to analyse, synthesise and apply critical judgement. Analysis is shown by explaining how the proposed solution operates in your own words as well as its benefits and consequences. Synthesis is shown through the organisation of your Related Work section and through identifying and generalising common aspects across different solutions. Critical judgement is shown by discussing the limitations of the solutions proposed both in terms of their disadvantages and limits of applicability. | ||
|
||
Typically you can look for Background work using different search engines including: | ||
|
||
Google Scholar | ||
IEEExplore | ||
ACM Digital Library | ||
Citeseer | ||
Science Direct | ||
Note 1: Often the terms Background, Literature Review, Related Work and State of the Art are used interchangeably. | ||
Note 2: Keyword search is wonderful, but you need the right Keywords. | ||
Note 2: IEEExplore, ACM Digital Library and Science Direct may require you to be on the College network to download the PDF versions of papers. If at home, use VPN. | ||
\end{comment} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,22 @@ | ||
\chapter{Background} % 10-20 pages | ||
\begin{comment} | ||
This should form the bulk of the interim report. You should consider that your objective here is to produce a near final version of the background section, as it will appear in your final report. All of this material should be re-usable, so it is worth getting it right at this stage of the project. The details of what to include can be found in the Project Report guidelines. | ||
|
||
From the Project Report guidelines: | ||
The background section of the report should set the project into context by relating it to existing published work which you read at the start of the project when your approach and methods were being considered. There are usually many ways of solving a given problem, and you shouldn't just pick one at random. Describe and evaluate as many alternative approaches as possible. The published work may be in the form of research papers found in the academic literature, articles, text books, technical manuals, or even existing software or hardware of which you have had hands-on experience. You must acknowledge the sources of your inspiration. You are expected to have seen and thought about other people's ideas; your contribution will be putting them into practice in some other context. However, avoid plagiarism: if you take another person's work as your own and do not cite your sources of information/inspiration you are being dishonest. When referring to other pieces of work, cite the sources where they are referred to or used, rather than just listing them at the end. Accidental plagiarism or not knowing how to cite and reference is not a valid reason for plagiarism. Make sure you read and digest the Department's plagiarism document . | ||
|
||
In writing the Background chapter you must demonstrate your ability to *analyse*, *synthesise* and *apply critical* judgement. Analysis is shown by explaining how the proposed solution operates in your own words as well as its benefits and consequences. Synthesis is shown through the organisation of your Related Work section and through identifying and generalising common aspects across different solutions. Critical judgement is shown by discussing the limitations of the solutions proposed both in terms of their disadvantages and limits of applicability. | ||
|
||
Typically you can look for Background work using different search engines including: | ||
* Google Scholar | ||
* IEEExplore | ||
* ACM Digital Library | ||
* Citeseer | ||
* Science Direct | ||
|
||
**Note 1:** Often the terms *Background, Literature Review, Related Work* and *State of the Art* are used interchangeably. | ||
**Note 2**: Keyword search is wonderful, but you need the right *Keywords*. | ||
**Note 3:** IEEExplore, ACM Digital Library and Science Direct may require you to be on the College network to download the PDF versions of papers. If at home, use VPN. | ||
\end{comment} | ||
|
||
\input{report/background/background.tex} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
File renamed without changes.
Oops, something went wrong.