Projects#
The projects will be available from week 3 and are designed to be extended pieces of work produced largely independently. The project type and assessment varies depending on how you are taking this course so please read the relevant sections carefully.
Choosing a Topic#
Taught Masters#
Students doing the taught masters should not use machine learning in your project.
We provide a choice of 3 “starting points” for your project. Each project contains some basic starter code, a bit of background information and some templates for the submission. Choose a project which piques your interest. Whilst each project provides access to an interesting source of data it is up to you to decide how to develop the project. We suggest coming up with a “scenario” (see individual projects for a few suggestions / examples). With that scenario in mind, we’d like you to think about how you could create a tool that would enable someone to easily interact with the data and extract something meaningful to them. Perhaps a way to visualise and interact with the data graphically or a set of functions and classes with a demo usage, that simplify extracting meaning from the data. Try to design your code so that it could be easily reused or adapted for broader related purposes beyond the one outlined in your scenario.
Research degrees (PhD or Masters)#
For those working on research degrees (PhD or Masters) you are welcome to choose any topic you like, but we would suggest picking something that may be helpful for your research. Please use the instructions for the taught masters project as a guide for what is required. The restriction around machine learning for the taught masters project students does not apply. Please also use the template for submission to assist us in giving you useful feedback.
Project Code Guidelines#
All the starter materials for the projects are supplied as an assignment, which you can synchronise in the same way you do with the exercises each week. If you use multiple computers please be careful to synchronise your files at the start and end of each session. You can work on and get help from staff during the workshops each week and we are happy to discuss both the overall shape of your project and the details of trying to get specifics to work.
Prior to submission please delete the files associated with the projects you decide not to use. We would prefer submissions as a Jupyter Notebook (*.ipynb). A template Jupyter notebook is provided that you can use. This should not only provide code but be structured with Markdown cells which explain:
The aim of the project / scenario and the problem it is solving
A high level overview in words of how the code works
A discussion of design decisions taken in structuring the code.
How would you develop / improve the code if given more time?
However, we are aware that some code eg guis, does not work well in Jupyter notebooks. If this is the case:
you should provide a
main.pyfile which runs your code.include any tests in a separate .py file.
Provide a pdf which covers the points above. As a guide we’d expect ~ 300-500 words.
In both formats, additional code / modules can also be included in other python files in the same repository if necessary and then imported. Make sure you use relative imports in your code.
Please make every effort to structure your code in a logical fashion to assist us in understanding it
In addition to the Jupyter Notebook / code files you should also submit:
a Conda environment file which enables your code to be run. Please ensure you test this on a Windows machine.
any output that cannot easily be embedded in the notebook (e.g an example data file or some visualisation, pdfs)
Your program should (as a rough guide):
do something meaningful within the context of your scenario
define at least two user functions (but typically more)
make use of appropriate specialist modules
comprise >~ 50 lines of actual code (excluding comments, imports and other ‘boilerplate’)
contain no more than 1000 lines in total (if you have written more, please isolate an individual element)
Referencing sources#
No one builds their computer programmes from scratch. At the very least pre-written compilers/interpreters turn high-level code into machine-level instructions. Typically we use many built-in functions, modules and packages. However, it should always be clear which modules you have imported. The assumption will be that the contents of such modules do not constitute part of your submission, unless their code is included in your submission. Furthermore, it is common practice to refer to code provided in documentation, examples, Q&A sites, and open source repositories, in the course of developing one’s own code. If you wish to directly include code from another source, you must clearly indicate its origin. Preferably, such code should be put it in a separate file, and imported into your own code in the same manner as any other standard-library or third-party module.
It is best practice to draw from multiple resources to instruct the creation of your own original code. However, where you do copy or adapt significant portions of code from a specific source and incorporate it in your own work, you should make it explicit that you have done so, and indicate where the original code came from, by commenting the code in an obvious manner.
Appropriate use of third-party code, eg specialist modules is encouraged and recognised positively in marking. However, we expect such material to be combined with significant amounts of your own code, to produce an original solution. We will also be looking for evidence that you understand your entire code at reasonable level. Note that we actively attempt to detect where code has been taken verbatim, or with trivial changes, from online sources or other student’s work and used without declaration.
Academic integrity:#
please ensure you read the full details of the academic integrity page about projects.