Aligning expectations

What is expected from you

Fulfilling prerequisites

A course like 22101/22161 Introduction to programming in Life Science using Python should enable you for this course.
Generally speaking, you must know simple Python well, which means you know the basic syntactical structure of Python (assignment, expressions, if, for while, some functions/methods), some data types (integer, float, string, lists, sets, dicts), and trivial file reading and writing, such that you relatively easy can solve minor programming tasks without any use of libraries. You can check if your abilities are up to par by solving some of the exercises in 22101/22161 above.
You must have your own computer (Windows, Mac, Linux) and you must understand it's file system structure - the folder hierarchy, file types, and file organization.

Special expectations

In the first week you learn Unix. You must work in this environment for the rest of the course. Unix is used in a number of (bioinformatic) courses, and being able to navigate in Unix is not only a survival skill, but also a skill sought in industry. All major bioinformatic efforts take place on big Unix servers/clusters.

In hand-ins you follow the skills taught in 22101, specifically how to write comments, using spacing to modularize the code, proper variable (object) naming, proper use of variables, error handling and code clarity, see Code construction.

Standard expectations

• You follow the course every week and hand in the required weekly exercises on DTU Learn.
• You peer-evaluate every week on DTU Learn. A hand-in is required for evaluation to be allowed.
• You do a project with a peer (i.e. a two person group project) at the end of the course.
• When getting help from TA's and teacher, understand that many students need help. You can not expect us to sit an hour with you. If time actually allows for it, we do not mind doing it.

Knowing the roles at the university

By knowing the roles of the various entities, you know where to direct your question.

• The teacher is responsible for the content of the course, the curriculum, the teaching, the project evaluation, the making and evaluation of the exam, and the reporting of cheating. In short - any content.
• The study office - and by extension - the exam office, the study guidance, and the legal office (cheating) deal with everything that is not course content. A lot of information is available on DTU Inside among that exam dates and what to do when having problems with the studies. They also process and publish the grades handed in by the teacher.

Course structure

The course is week-based, meaning new subjects are introduced Monday, and we work with them during the week. Sometimes smaller subjects are introduced Thursdays. In the last month of the course a programming project will be made in 2-person groups.

Exercises

• Weekly exercises are given every Monday. This constitutes an exercise set. There will be 12 of those. Exercises are mandatory.
• Exercises have to be uploaded to DTU Learn latest Sunday in the same week as the exercises were given.
• Peer evaluation of exercises are done in the following week on DTU Learn to be handed in Friday. The evaluations are mandatory.
• At least 10 of 12 evaluations must be handed in on DTU Learn for you to be allowed to take the exam. You can only evaluate if you have handed in exercises.
• Word or pdf documents are NOT accepted as hand-in - use only simple .txt or .py files.
  
• Solutions to each week's exercises are published before the next week's lesson on DTU Learn (under Discussions). Can be used as reference for peer evaluation.
• Exercises which are handed in after the solutions are published, are voided and will not count, no matter the reason for being late.
• Do not read ahead and start using functions/methods/libraries which will be covered later in the course.
• Purple exercises has to be done in pseudo code before you start implementing them in Python. The pseudo code is part of the hand-in for these exercises.
  So - make the pseudocode FIRST, then the real python programs AFTERWARDS for the purple exercises.

Why & How to peer-evaluate exercises

The peer evaluation is a central part of the learning process, using formative feedback. You can get input from your peers on how you can solve an exercise. You learn both by doing the evaluation and by receiving (reading) it.

You must use the criteria in Code construction in your own programs and the evaluation.

Projects, general information

• A project is done with two students in each group, no exceptions unless there is an odd number of students, in which case a one (wo)man group is formed. The teacher will form the groups, but will accept already formed groups, if informed in time, see the google sheet found via the announcement at DTU Learn.
• Each group will choose a project from the Project list in the last part of the course. If a group has an idea for a different project, this must be discussed with the teacher to see if it is feasible. Such a "home made" project must be of sufficient complexity, but not too complex either, and have clear goals, so it can be measured if it was failed or not.
• A project is estimated to be doable in 50 hours of work - people often use more time.
• The project work consists of two phases; 1) Doing a project - making code and writing report. 2) Individual (not in the group) peer evaluation of another groups project. Thus every project is peer evaluated twice. Both phases are mandatory.
• The teacher will evaluate all projects and peer evaluations. Understand that YOUR evaluation of another groups project is part of YOUR project work, and as such it will be part of YOUR grade.
• The project work will count for 50% of the final grade. The project grade is thus combined from the group effort of doing a project and the individual effort of peer grading a project.
• The project will be handed in through DTU Learn at the time written in the Programme.
• The teacher will distribute the projects per mail for peer evaluation with the intention of NOT evaluation the same type of project you made.
• The evaluation of another groups project will be handed in 1 week later on DTU Learn.

Getting help with the project

• The groups can consult the teacher and the TA's on problems with the projects. The teacher has the best overview, while TA's often can only help with actual problems in the code.
• Groups can talk to each other on their project, but actual cooperation between groups with the same project is not allowed. Here is a simple and clear rule:
  Groups must not show any written material (typically code or report) to any other group.
• Consulting Google on programming issues is fine, but understand what is being said/written and why it works.
• Nothing but Python libraries which have been taught in the course can be used in projects. Consult the teacher if in doubt.
• The teacher should be informed if a group is dysfunctional. We will work something out.

Content of the project

Each project consists of:

• A report, preferably in PDF.
• The program code.
• Any data files of relevance not supplied through the course.
• A signed version of this statement.
  DO NOT FORGET
  It is unfortunate when students fail because they forget a mandatory element.

The report itself

The report should be written is such a way that it can be understood by your peer (fellow student), who have no knowledge of the specifics of your project. I have provided some sources of help, for writing reports, etc. at university level.

• PDF: Vejledning i opbygning og skrivning af rapporter
• PDF: Guide on how to write a report
• Online: How to structure a science paper
• PDF: Master Thesis Advice
• Online: How to write a thesis

It is considered unlikely that that the report is less than 4 pages, but there is no set limitation. The report is evaluated by quality, not by length. Some projects are naturally heavy in theory, others have a more practical approach, and the report is expected to reflect that to some extent.

The following sections can/should be in the report in approximately this order:

• Introduction - mandatory
• Contribution - mandatory
• Theory - mandatory
• Algorithm design - mandatory
• Program design - mandatory
• Program manual - mandatory
• Results - optional, depends a bit on the project if it is natural to include
• Runtime analysis - mandatory
• (Unit) Testing - mandatory
• Conclusion - mandatory
• References - mandatory if any references

The sections are explained in detail below. It is important that the report reads naturally with easy flow from one subject to the next. It should also be a coherent logical structure. As an example you must explain a concept/system/method before you use it - not use it first and later tell what it means. Nor should you write the same thing twice. The report must cover all sections in some form, but as the projects are different, different emphasis will be placed on the different sections. An example is that the Theory section is important for project 9-11, but much less important and "theoretical" for project 1,3,4,5. Results are really important in project 5 and 6, but much less in the rest. The sections on "Theory", "Algorithm design" and "Program design" can sometimes content-wise overlap each other depending on the nature of the project - it can be a question of simply drawing a line.

The code

• The program code as .py or .txt files. It is a separate file from the report.
• The code should be clearly structured and well commented so it is possible to follow your thinking.
• The major data structures should also be explained with structure and purpose.
• The code should obviously follow the guidelines that has been given during the course in exercises.

Report sections

• Introduction - A short section explaining why your project and program is important and useful and in which context it should be used. Can also be used to introduce some background.
• Contribution - The should be made clear, who contributed to which parts of the project, if the contributions are uneven or clearly split up. For a group that worked closely together (the best), it is completely fine to write "equal contribution" from all members, if such is the case and it is not clear who has the main contribution. "Equal contribution" is also fine for situations where the main author of pieces of code and sections of reports changes in the group such that both members have roughly contributed evenly on both programming and writing. Caveat: If you write "equal contribution" you will pass or fail together.
• Theory - If you have math, equations, systems, ideas that lies behind the code you do, then it should be described and explained here. Any "facts" that you are using in the code or programming against should be described in this section. High-level decisions you make, that affects how the code will work, could be described - could be using a specific library.
• Algorithm design - Every project has at least one "core" algorithm or method that the project revolves about. In this section you explain how the core algorithm(s) works. Pseudo code is great for making a structure you can explain it from. Some people use diagrams.
• Program design - This is where you give an overview of your program: where are your functions, where is your input and output, where is the main core. To show the structural overview of your program, pseudo code is again a great method.
• Program manual - Describe how to use the program(s), input format, various program options, expected output, example runs. Some screenshots works great here.
• Results - Show/describe/list your results of the program runs in this section.
• Runtime analysis - In this section you analyze the performance of the program in Big O terms, see Runtime evaluation of algorithms. You must present calculations supported by arguments, not just results.
• Conclusion - Talk about the results you achieved, if you have not done so already. Discuss strength and weaknesses of the program/algorithm. Future goals or improvements.
• References - If you used articles, web resources, or other information sources during the project, these need to be stated here.

Some people thinks the algorithm design overlaps a lot with program design, and while there is some truth to that, then algorithm design is detailed about the central algorithm/part, while program design gives an overview of the code, so a reader can easily find the section of interest.

How to evaluate the project

The projects consists of two very different parts: The report and the program/code. They must be evaluated in different ways, but both evaluations must result in some written text.
Here is a template evaluation document, which you can use if you wish.

The report

The report should be evaluated on form and content. It should be understood that the report must be well structured and argued, so somebody not familiar with the subject can understand it.
Form: This consists of spelling, meaningful sentences, good language. Importantly, the sections as described above must be present. The sections: "Theory", "Algorithm design" and "Program design" should be appropriate for the project type and some flexibility is allowed.

Content: The content should obviously be correct and be evaluated in the light of the descriptions of the different report sections above.

The program(s)

The code is evaluated on our usual criteria for exercises as can be seen on Code construction and in peer evaluation for the exercises. I will shortly mention correctness, structure, readability as the main focus.

Passing the course

The grade in the course is pass/fail. There are two parts which (according to DTU rules) both have to be passed in order to pass the course.

1. The 4 hour written exam with all aids allowed. Weight 50%.
2. The project work (project + peer evaluation). Weight 50%.

Furthermore, the weekly exercises + peer evaluations are mandatory. At least 10 out of 12 exercise sets + peer evaluations must be handed in to be allowed in exam participation.
If you fail the exam, but pass the project, you only have to do a re-exam and vice versa. Failing both is a do-over.

Conduction of the exam

• The course is using Digital Exam.
• You must use your own computer for the exam. According to DTU rules, any technical problems with your computer during the exam is your responsibility and you will get no extra time or leniency if it breaks. You will be evaluated on what you (not) hand in.
• Internal censoring is used, meaning the teacher and a qualified colleague will grade the exam as pass/non-pass.
• The exam is with all aids allowed, but there will NOT be open internet. This is following the standard DTU exam template. All aids covers written material like course powerpoints, books and exercises.

Exam purpose

The exam tests your ability in practical Python and programmatic problem solving.

To say it plainly: Can you create Python code that can solve a minor computational problem? That is a major goal of the course.

In particular, the exam addresses the following learning objectives, some only partly:

• Demonstrate and explain the python syntax, object mode, data structures, classes and 65-70 Python methods/functions.
• Exercise pattern recognition in (bioinformatic) data files in order to extract information.
• Apply methods/programming techniques demonstrated in the course to similar problems.
• Analyze a (programming) problem and ascertain its components, and create an efficient solution by applying the right components in the right order.
• Analyze a program and based on its behavior, locate and eradicate errors.
• Write clear, precise and well documented code, which is suitable for greater collaborative efforts.
• Utilize code libraries, both scientific and other, for fast and good solution of programming tasks.

What actually happens at exam

You will get a pdf with 2 Python programming assignments. Each assignment (which tells you what to do) has a number of input files and a number of output files, which you download. You are supposed to create 2 programs that can generate the appropriate output file(s) from the relevant input file(s) according to the assignments. There should be no confusion about what you have to generate as you have the correct output available. When done or time is up, you hand in (upload) your programs.

If you manage to reproduce output files which are binary identical to the output files from the assignment, then you have automatically passed, because you have demonstrably achieved a major course goal.
If you did not reproduce the output files, then your code will be inspected and evaluated by the teacher. If it is meaningful and sensible (see learning objectives) you will pass. Reproducing one of the output files, i.e. solving one of the assignments is not enough for a pass, but it is a good start.

How to see if files are binary identical?

In Unix (you are using Unix, right? The course is conducted with that in mind) you can do a (md5) checksum.

md5sum file1 file2

If the checksums are the same, the files are identical.
You can also do a diff.

diff file1 file2

If they are identical, nothing happens. If not, you will be informed about the differences - in a confusing way until you learn to decipher it.

If you are uncertain about this, maybe you should practice a few times before the exam. You can also google for it, because there are many ways of doing this.

The project work

In the project all aids are allowed, like books, powerpoints, google, teachers, or knowledge sources. Make sure you understand what you are told/read. Uncritical copy/paste is not going to help you or the project. Make references when relevant.
"All aids" does not cover what normally constitutes cheating, like copying other students work or copying from solutions found on the internet or using libraries that solves the entire problem for you.

The teacher will grade the project work. It consists of 3 parts. The report, the code and the peer evaluation.
The project work addresses the following learning objectives, some only partly:

• Use the command line of Unix with 10-15 common Unix commands, inclusive file system navigation, pipelines, process and file system control.
• Demonstrate and explain the python syntax, object mode, data structures, classes and 65-70 Python methods/functions.
• Exercise pattern recognition in (bioinformatic) data files in order to extract information.
• Apply methods/programming techniques demonstrated in the course to similar problems.
• Analyze a (programming) problem and ascertain its components, and create an efficient solution by applying the right components in the right order.
• Analyze a program and based on its behavior, locate and eradicate errors.
• Evaluate the quality of the code, based on criteria shown in the course, and ensuring the code meets quality standards by employing the unit test technique.
• Write clear, precise and well documented code, which is suitable for greater collaborative efforts.
• Evaluate the performance and efficiency of code with respect to speed and memory consumption using Big O notation.
• Utilize code libraries, both scientific and other, for fast and good solution of programming tasks.

The project will be evaluated on a overall view of how well it answers the problems stated in the project description. Below are various elements specified.

General engineering competences relevant for the project work

Ability to write coherent text, to form proper sentences in English, to finish a consistent quality product (head lines, TOC, no missing words or figures, using same words for concepts, using the right scientific word/concept, etc.). Ability to collaborate both in writing text and programming code with other people.

Skills and competences relevant for the report, which will form the foundation of the evaluation

• Analyze the project formulation and develop a method/algorithm for solving the problem.
• Clearly describe theoretical aspects of the project and/or algorithm; this could be mathematical foundation, input file data formats, categories used, prerequisites and assumptions, data structure elements or clever ideas.
• Clearly and coherently describe the algorithm and relevant data structures.
• When designing an algorithm, it can suffer from performance problems, which can be related to both speed and excessive use of memory. Can you recognize the shortcomings in your own algorithm?
• Show the proper use of pseudo code.
• Appropriate use of figures, graphs, illustrations and screenshots.
• Demonstrate the actual structure of the finished program, so the reader can understand what is going on where when seeing the code.
• Evaluate what is trivial and what is not, and focus on explaining the non-trivial things in the program.
• Understand and clearly describe a runtime evaluation of your code in Big O notation.
• Present results from the project in a relevant and clear fashion.
• See the perspective of your project. Where can it be used? What can be improved? What did you learn?
• Building a project is a creative process. Let that creativity shine through.

Skills and competences relevant for the code, which will form the foundation of the evaluation

During the course you have been presented for many skills and competences in the peer evaluation and through that gained a good grasp of the easier coding skills.

• Correct commenting in code, placement and content
• Spacing and modularization
• Object naming
• Using appropriate amount and type of variables for the task.
• Error handling

The project demands more of the in-depth coding skills.

• Avoiding simple structural flaws
• Ability to write clear and precise code.
• Writing concise code.
• Writing sensible and meaningful code. This is not included by above points.
• This point is about significant performance problems not related to an inherent problem with the algorithm (which is covered in the report).

1. Recognizing and avoiding unnecessary loops or methods which slow the speed of the program.
2. Recognizing and avoiding unnecessary use of computer memory.

• Reach for beauty and elegance. That happens when it all comes together in a clear and obvious chain of events that leads to the result.

Skills and competences relevant for the peer evaluation

• You will use many of the competences used in your own report and code.
• Ability to critically read and evaluate text and foreign code (see through bullshit).

Failing the course

The course has two parts, which must both be passed in order to pass the course: Project and exam.
There are also the weekly exercises and peer evaluations, which are mandatory to hand in for you to be allowed to take the exam. They do not count in passing the course, but consistently doing poorly in exercises is not going to aid the project or the exam.

Failing the exam

This is the most frequent way of failing the course. Said in simple words, the exam tests your ability - when faced with a problem - to produce meaningful code that solves the problem. As can be seen by the text above, it is not strictly required that the code works. That is just an easy way to measure ability. What is required, is that the code is meaningful given the problem. Half done, or explaining what you intend is not sufficient.

The 4 challenges for failing students are:

• difficulty in analyzing the problem - understanding what has to be done.
• difficulty in formulating a strategy for solving the problem - designing the method/algorithm.
• difficulty in executing the strategy - transforming the method/idea into working code.
• difficulty in making the code coherent - having the grand overview of the method/code.

There are lots of mistakes a student can do at an exam; insufficient knowledge of python (syntax and functions), bad performance, repetitive code, missing variables, wrongly iterating loops, missing the right position of sequences etc., but they are not disastrous on the individual level - although they reflect your skill. The problem is when many mistakes/omissions come together and form a mix of the 4 challenges.

If you have not improved on these 4 points when you are taking an re-exam, the result is quite predictable.
How to improve: Practice, practice, and then some practice. You can not read it in a book or powerpoint, or see the videos again. That helps in knowing the syntax and functions of python, but that is not the issue. The issue is training your brain in the analyzing, formulating and executing phases of coherent programming.

Failing the project

The reasons for failing the project are usually:

• more than one severe, game changing mistake has been made in the code.
• severe misunderstandings about the content/purpose of the project.
• too low quality in code and report.

The first two could somewhat easily be avoided by consulting the teacher. The last... you need to up your game; Take the time to write a decent report - there are resources available on how to do that. The code can/must be improved by learning more during the course - study the exercises and the solutions. A lot of the same reasons for failing the exam also apply here.