22118 - User contributions [en]

Data analysis

2026-05-27T07:43:06Z

WikiSysop: /* Description */

__NOTOC__
===Description===
This project is about analyzing specific data and answer various questions about it. The data file is a flat file database constructed in year 2000 with various information about people, and can be seen here as
[https://teaching.healthtech.dtu.dk/material/22118/people.db people.db].
The program must read this file ONCE - line by line - not storing the actual lines for future reference, but entering the data in an appropriate data structure of your own devising. The questions are sometimes asking if some distribution is "normal". "Normal" here does '''not''' mean
fit the bell curve (standard normal distribution). It means reasonable or natural, what you would expect. 
The program must now answer the following questions:

# Is the age and gender distribution normal/sensible in the database? A yes/no answer is not good enough.
# At what age does the men become fathers first time (max age, min age, average age)?
# Is the distribution of first-time fatherhood age normal/sensible? A yes/no answer is not good enough.
# At what age does the women become mothers first time (max age, min age, average age)?
# Is the distribution of first-time motherhood age normal/sensible? A yes/no answer is not good enough.
# How many men and women do not have children (in percent)?
# What is the average age difference between the parents (with a child in common obviously)?
# How many people has at least one grandparent that is still alive? A person is living if he/she is in the database. State the number both in percent and as a real number.
# How many has at least one cousin in the data set? What is the average number of cousins based on those who have cousins? Note: This number is historically difficult to compute right, but here are some thoughts to help you out in verifying your count. You have to construct a method for finding cousin pairs. Any cousin pair you identify, can be written as a tuple (cpr1, cpr2) in a list. a) There should be no duplicate tuples in the list - you are not cousins with the same person more than once. b) There should be no tuple with the same cpr on position 1 and 2 - you are not cousins with yourself. c) Because of symmetry, it is expected that for any (cpr1, cpr2) tuple there is a (cpr2, cpr1) tuple - when you are cousins with somebody, somebody is cousins with you. This has natural consequences: Set(cpr1) == Set(cpr2), Sorted_list(cpr1) == Sorted_list(cpr2). d) This list does NOT discover sibling pairs inserted as cousins, however there should be no overlap of this list and a similar list covering sibling pairs. e) The length of the list of cousin tuples is the number of cousin pairs, and the size of the set of cpr's is the number of people who have cousins.
# Is the firstborn likely to be male or female?
# How many men/women (percentage) have children with more than one woman/man?
# Do tall people marry (or at least get children together)? To answer that, calculate the percentages of tall/tall, tall/normal, tall/short, normal/normal, normal/short, and short/short couples. Decide your own limits for tall, normal and short, and if they are the same for men and women.
# Do tall parents get tall children?
# Do fat people marry (or at least get children together)? To answer that, calculate the percentages of fat/fat, fat/normal, fat/slim, normal/normal, normal/slim, and slim/slim couples. Decide your own limits for fat, normal and slim. Calculate the BMI, and let that be the fatness indicator.
# Using the knowledge of [https://en.wikipedia.org/wiki/Blood_type#ABO_blood_group_system blood group type inheritance], are there any children in the database where you can safely say that at least one of the parents are not the real parent. If such children exists, make a list of them. In the report you must discuss how you determine that the parent(s) of the child are not the "true" parents.
# Make a list of fathers who can donate blood to their sons. The list must identify the father and the son(s) and their blood type. You must write the length of the list in the report, together with the number of fathers and the number of sons.
# Make a list of persons who can donate blood to at least one of their grandparents. The list must identify must the person, the grandparent(s) and their blood type. You must write the length of the list in the report, together with the number of grandchildren and the number of grandparents.

All questions has to answered in one run of the program, but not necessarily in that order. You are welcome to answer other interesting questions, that can be posed from the data. Many questions are about distributions and if the distributions are "normal". The program can calculate the distributions, but the analysis of the result (evaluating normalcy) is to be in the report.
I will come with an example: "Is the distribution of first-time fatherhood age normal? A yes/no answer is not good enough." You must at least calculate and print something like:
Age Percentage
16-20: 5%
21-25: 10%
26-30: 40%
31-35: 30%
36-40: 15%
41-45: 0%
From that you simply evaluate if it is normal and put it in the report. I think above numbers are rather normal, but below are very strange. If you want to, you can support your opinions with references to [https://www.dst.dk/en/ Statistics Denmark].
Age Percentage
16-20: 0%
21-25: 0%
26-30: 10%
31-35: 20%
36-40: 50%
41-45: 20%

The problem you should solve in the project is not "how to make good statistics", but "how to collect the data from the database". If you feel you can do better statistics than above, you are welcome.

'''Tip''': For the sanity of the questions you should assume/pretend you are doing this analysis primo 2000. 
'''Tip''': The CPR consists of a date part (first 6 numbers as DDMMYY) which is the birthday, and a 4 digit number. There are rules about how CPR should be constructed, and they are not followed since it is illegal to publish CPR numbers. What you need to know is that the date part is a date in 1900-1999, and the last digit is significant; odd - male, even - female. 
'''Tip''': The data are somewhat randomly constructed, so you can find 'facts' that seem very unlikely, like 6 year old kids with a height of 2 m. Just accept it. 
'''Tip''': In the database the children of a person is clear. This means you can follow a thread ''down'' the generations. As can be seen from some of the questions, it can nice to find the parents directly from a child, i.e follow a thread ''up'' the generations. Can you find a way to do this easily? 
'''Fun fact''': A journalist once called me to know more about the database, smelling a privacy leak scandal in the making, This is the reason why the data set is strange in various ways. There should be no suspicion of a leak - expect maybe to journalists who would rather create sensational news than do a proper fact finding job.

Searching for motifs in sequences

2026-05-21T16:39:27Z

WikiSysop: /* Input and output */

__NOTOC__
===Description===
A sequence motif is typically a short sequence pattern of DNA or amino acid sequence that is conserved across various gene families or organisms. Sequence motifs are recognizable and could be a promoter, a binding site or a domain that folds into a specific structure. The mechanism for finding motifs is often Hidden Markov Models or Neural Networks, which both require a lot of examples of the motif to work, but here you will explore a different method, which just needs a consensus sequence (or what you think the consensus sequence is). It uses a model where sites in the sequence are weighted after importance and finds those matches which are close. 
The program is given a fasta file with DNA or amino acid sequences and a file containing a description of the signal to search for. It will then display all occurrences of a match in each fasta entry.

===Input and output===
The program is given a fasta file, a signal description file and a deviation (a number) as input on the command line. Deviation is the deviation allowed from the original signal description.
The fasta file can contain more than one sequence/entry.
The signal description file is a tab separated file. Each line consists of either
1) one or more allowed letters at this position and a penalty for having a mismatch at that position.
2) the star character * denoting unimportant characters in the sequence and an interval where these unimportant characters are allowed.
3) the hash character # meaning this line is a comment, and should be ignored by the program.

As an example of a signal description file, here is a prokaryotic promoter, which is a 2-parts signal that can be described as:

# -35 element
T 7
T 8
G 6
A 5
C 5
A 5
# intervening unimportant bases
* 15-21
# -10 element
T 8
A 8
T 6
A 6
AT 5
T 8

The output should list all matches in each fasta entry, clearly stating the location of the match. 
Note that a description file can describe a simple 1-part signal, a 2-part signal as shown here, a 3-part signal by adding another *-line plus bases, and so forth. It is strongly preferred that the program can handle all such cases.

===Details===
The deviation is an important factor. If the deviation is set to 0, then search for the signal is reduced to an exact match. If the deviation is set to 16 in the above example, then mismatches with the combined penalty of 16 or less are allowed. In the promoter example the following signals would match (ignoring intervening bases, not complete list):
TTGXXX*TATAAT
TTGACA*XXTAAT
TTGXXA*TAXAAT

Note: I do not consider an approach based heavily on regular expression as a good idea, but you are free to do as you like. Due to the flexibility in the signal caused by the gaps, several different matches can be found from a specific position in the sequence. You should find all matches, not just the first one.
It needs to be understood that the program/algorithm is completely general and can search for any kind of signal in any kind of text sequences. It is not limited to life science.

Fasta file to use as example in the projects: [https://teaching.healthtech.dtu.dk/material/22118/motif.fsa motif.fsa]

Aligning expectations

2026-05-12T08:43:17Z

WikiSysop: /* The project work */

== What is expected from you ==
=== Fulfilling prerequisites ===
A course like [https://kurser.dtu.dk/course/22116 22116/22166 Python programming in Life Science] 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 22116/22166 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 weeks 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 22116, 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, 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 [https://student.dtu.dk/en/ Student DTU] 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 [https://learn.dtu.dk DTU Learn] latest Sunday in the same week as the exercises were given.
* Peer evaluation of exercises are done in the following week on [https://learn.dtu.dk 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. Sometimes, like with unit test, an entire folder structure should be zipped and uploaded. 
* 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 Course Overview in Content 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 group must work together using git and GitHub when developing the program. If the report is written in LateX, or other pure text-based format, git could also be used here.
* 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 [https://teaching.healthtech.dtu.dk/material/22118/ProjectStatement22118.pdf statement]. <div style="color:red;display:inline;">DO NOT FORGET</div> It is unfortunate when students fail because they forget a mandatory element.
* The teacher must have access to the project repo. Make sure to invite ''peterwadsackett'' or attach a zipped repo when handing in.

==== 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: [https://teaching.healthtech.dtu.dk/material/22113/Vejledning_i_opbygning_og_skrivning_af_rapporter_v.2013.3.pdf Vejledning i opbygning og skrivning af rapporter]
* PDF: [https://teaching.healthtech.dtu.dk/material/22113/how_to_write_reports.pdf Guide on how to write a report]
* Online: [https://www.elsevier.com/connect/11-steps-to-structuring-a-science-paper-editors-will-take-seriously How to structure a science paper]
* PDF: [https://www.imm.dtu.dk/~janba/MastersThesisAdvice.pdf Master Thesis Advice]
* Online: [https://thereader.mitpress.mit.edu/umberto-eco-how-to-write-a-thesis/ 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.
* Unit testing of at least part of the code should be included. This can be done as a separate folder with test and test data.

==== 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.
* '''Unit Testing''' - Write a small section about what unit test you made on what sections of the code. Disclose if you found errors by writing the tests.
* '''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 [https://teaching.healthtech.dtu.dk/material/22118/projectevaltemplate.docx 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. You have to do satisfactory (pass) in the project work. 
Furthermore, the weekly exercises + peer evaluations are mandatory. At least 10 out of 12 exercise sets + peer evaluations must be handed in to get your project evaluated for passing. 

=== The project work ===
In the project all aids are allowed, like books, powerpoints, google, teachers, or knowledge sources. Being overly dependent on AI for your solution is not accepted. 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 substantial parts of the 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).
# Recognizing and avoiding unnecessary loops or methods which slow the speed of the program.
# 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 exercises are mandatory. You must hand-in minimum 10 of the 12. Likewise you must peer-evaluate 10 out of 12 times. You can't peer-evaluate if you do not hand in. Failing to achieve this will make you fail the course - no matter the state of your project. 
The exercises do not count in passing the course, but consistently doing poorly in exercises is not going to aid the project.

=== 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 the report.
* too low quality in the code.
* insufficient contribution in either code or report.
The first two could somewhat easily be avoided by consulting the teacher. 
For the last reasons... you need to up your game; Take the time to write a decent report - there are resources available on how to do that. 
Insufficient contribution often has an underlying course in insufficient coding skills. 
The code can/must be improved by learning more during the course - study the exercises and the solutions.

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; 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.

How to improve: Practice, practice, and then some practice. You can not read it in a book or powerpoint. 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.

Aligning expectations

2026-05-12T08:42:09Z

WikiSysop: /* How to evaluate the project */

== What is expected from you ==
=== Fulfilling prerequisites ===
A course like [https://kurser.dtu.dk/course/22116 22116/22166 Python programming in Life Science] 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 22116/22166 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 weeks 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 22116, 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, 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 [https://student.dtu.dk/en/ Student DTU] 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 [https://learn.dtu.dk DTU Learn] latest Sunday in the same week as the exercises were given.
* Peer evaluation of exercises are done in the following week on [https://learn.dtu.dk 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. Sometimes, like with unit test, an entire folder structure should be zipped and uploaded. 
* 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 Course Overview in Content 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 group must work together using git and GitHub when developing the program. If the report is written in LateX, or other pure text-based format, git could also be used here.
* 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 [https://teaching.healthtech.dtu.dk/material/22118/ProjectStatement22118.pdf statement]. <div style="color:red;display:inline;">DO NOT FORGET</div> It is unfortunate when students fail because they forget a mandatory element.
* The teacher must have access to the project repo. Make sure to invite ''peterwadsackett'' or attach a zipped repo when handing in.

==== 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: [https://teaching.healthtech.dtu.dk/material/22113/Vejledning_i_opbygning_og_skrivning_af_rapporter_v.2013.3.pdf Vejledning i opbygning og skrivning af rapporter]
* PDF: [https://teaching.healthtech.dtu.dk/material/22113/how_to_write_reports.pdf Guide on how to write a report]
* Online: [https://www.elsevier.com/connect/11-steps-to-structuring-a-science-paper-editors-will-take-seriously How to structure a science paper]
* PDF: [https://www.imm.dtu.dk/~janba/MastersThesisAdvice.pdf Master Thesis Advice]
* Online: [https://thereader.mitpress.mit.edu/umberto-eco-how-to-write-a-thesis/ 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.
* Unit testing of at least part of the code should be included. This can be done as a separate folder with test and test data.

==== 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.
* '''Unit Testing''' - Write a small section about what unit test you made on what sections of the code. Disclose if you found errors by writing the tests.
* '''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 [https://teaching.healthtech.dtu.dk/material/22118/projectevaltemplate.docx 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. You have to do satisfactory (pass) in the project work. 
Furthermore, the weekly exercises + peer evaluations are mandatory. At least 10 out of 12 exercise sets + peer evaluations must be handed in to get your project evaluated for passing. 

=== The project work ===
In the project all aids are allowed, like books, powerpoints, google, teachers, or knowledge sources. Being overly dependent on AI for your solution is not accepted. 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).
# Recognizing and avoiding unnecessary loops or methods which slow the speed of the program.
# 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 exercises are mandatory. You must hand-in minimum 10 of the 12. Likewise you must peer-evaluate 10 out of 12 times. You can't peer-evaluate if you do not hand in. Failing to achieve this will make you fail the course - no matter the state of your project. 
The exercises do not count in passing the course, but consistently doing poorly in exercises is not going to aid the project.

=== 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 the report.
* too low quality in the code.
* insufficient contribution in either code or report.
The first two could somewhat easily be avoided by consulting the teacher. 
For the last reasons... you need to up your game; Take the time to write a decent report - there are resources available on how to do that. 
Insufficient contribution often has an underlying course in insufficient coding skills. 
The code can/must be improved by learning more during the course - study the exercises and the solutions.

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; 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.

How to improve: Practice, practice, and then some practice. You can not read it in a book or powerpoint. 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.

Aligning expectations

2026-05-11T15:36:54Z

WikiSysop: /* Content of the project */

== What is expected from you ==
=== Fulfilling prerequisites ===
A course like [https://kurser.dtu.dk/course/22116 22116/22166 Python programming in Life Science] 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 22116/22166 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 weeks 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 22116, 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, 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 [https://student.dtu.dk/en/ Student DTU] 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 [https://learn.dtu.dk DTU Learn] latest Sunday in the same week as the exercises were given.
* Peer evaluation of exercises are done in the following week on [https://learn.dtu.dk 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. Sometimes, like with unit test, an entire folder structure should be zipped and uploaded. 
* 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 Course Overview in Content 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 group must work together using git and GitHub when developing the program. If the report is written in LateX, or other pure text-based format, git could also be used here.
* 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 [https://teaching.healthtech.dtu.dk/material/22118/ProjectStatement22118.pdf statement]. <div style="color:red;display:inline;">DO NOT FORGET</div> It is unfortunate when students fail because they forget a mandatory element.
* The teacher must have access to the project repo. Make sure to invite ''peterwadsackett'' or attach a zipped repo when handing in.

==== 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: [https://teaching.healthtech.dtu.dk/material/22113/Vejledning_i_opbygning_og_skrivning_af_rapporter_v.2013.3.pdf Vejledning i opbygning og skrivning af rapporter]
* PDF: [https://teaching.healthtech.dtu.dk/material/22113/how_to_write_reports.pdf Guide on how to write a report]
* Online: [https://www.elsevier.com/connect/11-steps-to-structuring-a-science-paper-editors-will-take-seriously How to structure a science paper]
* PDF: [https://www.imm.dtu.dk/~janba/MastersThesisAdvice.pdf Master Thesis Advice]
* Online: [https://thereader.mitpress.mit.edu/umberto-eco-how-to-write-a-thesis/ 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.
* Unit testing of at least part of the code should be included. This can be done as a separate folder with test and test data.

==== 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.
* '''Unit Testing''' - Write a small section about what unit test you made on what sections of the code. Disclose if you found errors by writing the tests.
* '''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 [https://teaching.healthtech.dtu.dk/material/22113/projectevaltemplate.docx 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. You have to do satisfactory (pass) in the project work. 
Furthermore, the weekly exercises + peer evaluations are mandatory. At least 10 out of 12 exercise sets + peer evaluations must be handed in to get your project evaluated for passing. 

=== The project work ===
In the project all aids are allowed, like books, powerpoints, google, teachers, or knowledge sources. Being overly dependent on AI for your solution is not accepted. 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).
# Recognizing and avoiding unnecessary loops or methods which slow the speed of the program.
# 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 exercises are mandatory. You must hand-in minimum 10 of the 12. Likewise you must peer-evaluate 10 out of 12 times. You can't peer-evaluate if you do not hand in. Failing to achieve this will make you fail the course - no matter the state of your project. 
The exercises do not count in passing the course, but consistently doing poorly in exercises is not going to aid the project.

=== 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 the report.
* too low quality in the code.
* insufficient contribution in either code or report.
The first two could somewhat easily be avoided by consulting the teacher. 
For the last reasons... you need to up your game; Take the time to write a decent report - there are resources available on how to do that. 
Insufficient contribution often has an underlying course in insufficient coding skills. 
The code can/must be improved by learning more during the course - study the exercises and the solutions.

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; 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.

How to improve: Practice, practice, and then some practice. You can not read it in a book or powerpoint. 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.

Changing existing code base

2026-05-08T11:24:44Z

WikiSysop: /* Exercises to be handed in */

__NOTOC__
{| width=500 style="font-size: 10px; float:right; margin-left: 10px; margin-top: -56px;"
|Previous: [[Runtime evaluation]]
|Next: [[Last words]]
|}
== Opportunity ==
PDF: [https://teaching.healthtech.dtu.dk/material/22118/RNA-editing_Masterproject.pdf RNA Editing] A Master project. Contact Greg, grinos@dtu.dk

== Required course material for the lesson ==
GitHub: [https://github.com/agormp Professor Anders Gorm Pedersen's repositories.] Used in teaching this week. 
GitHub: [https://github.com/genenetwork/ Gene network.] A much larger and thus more complicated/confusing repo. They are looking for help/contributers 
GitHub: [https://github.com/bioinform The Bioinformatics Repository.] Different repos, various languages. 


== Subjects covered ==
Hands-on addition to a code base,

== Exercises to be handed in ==
There are going to be only one exercise. You have the project, and the exercise will be big. 
Clone Anders Gorm's repo: ''sequencelib'' and study it. 
'''Make it able to read FASTQ files.''' 
This includes changing the Seqfile class, adding a new Fastqfilehandle class, and understanding the Sequence class really well. Most likely other stuff. 
Of course, you are using Git to handle your changes. You might make some kind of limitation somewhere (f.ex. do not implement reading from stdin) or maybe generator,
as FASTQ files get really big and can't all be in memory. 
FASTQ are often gzipped - it is nice to read them directly from the gzip file, but it makes the entire improvement harder. 
You don't know FASTQ format? - look it up - this is supposed to be a "real world problem". You don't get much help. 
[https://teaching.healthtech.dtu.dk/material/22118/BRISCOE_0069_BD18RUACXX_L2_1_pf.fastq Example of an uncompressed FASTQ file]

== Exercises for extra practice ==

Changing existing code base

2026-05-08T11:10:16Z

WikiSysop: /* Exercises to be handed in */

Changing existing code base

2026-05-07T09:56:10Z

WikiSysop: /* Exercises to be handed in */

__NOTOC__
{| width=500 style="font-size: 10px; float:right; margin-left: 10px; margin-top: -56px;"
|Previous: [[Runtime evaluation]]
|Next: [[Last words]]
|}
== Opportunity ==
PDF: [https://teaching.healthtech.dtu.dk/material/22118/RNA-editing_Masterproject.pdf RNA Editing] A Master project. Contact Greg, grinos@dtu.dk

== Required course material for the lesson ==
GitHub: [https://github.com/agormp Professor Anders Gorm Pedersen's repositories.] Used in teaching this week. 
GitHub: [https://github.com/genenetwork/ Gene network.] A much larger and thus more complicated/confusing repo. They are looking for help/contributers 
GitHub: [https://github.com/bioinform The Bioinformatics Repository.] Different repos, various languages. 


== Subjects covered ==
Hands-on addition to a code base,

== Exercises to be handed in ==
There are going to be only one exercise. You have the project, and the exercise will be big. 
Clone Anders Gorm's repo: ''sequencelib'' and study it. 
'''Make it able to read FASTQ files.''' 
This includes changing the Seqfile class, adding a new Fastqfilehandle class, and understanding the Sequence class really well. Most likely other stuff. 
Of course, you are using Git to handle your changes. You might make some kind of limitation somewhere (f.ex. do not implement reading from stdin) or maybe generator,
as FASTQ files get really big and can't all be in memory. Also, FASTQ are often gzipped - it is nice to read them directly from the gzip file. 
You don't know FASTQ format? - look it up - this is supposed to be a "real world problem". You don't get much help.

== Exercises for extra practice ==

Changing existing code base

2026-05-07T09:55:58Z

WikiSysop: /* Exercises to be handed in */

__NOTOC__
{| width=500 style="font-size: 10px; float:right; margin-left: 10px; margin-top: -56px;"
|Previous: [[Runtime evaluation]]
|Next: [[Last words]]
|}
== Opportunity ==
PDF: [https://teaching.healthtech.dtu.dk/material/22118/RNA-editing_Masterproject.pdf RNA Editing] A Master project. Contact Greg, grinos@dtu.dk

== Required course material for the lesson ==
GitHub: [https://github.com/agormp Professor Anders Gorm Pedersen's repositories.] Used in teaching this week. 
GitHub: [https://github.com/genenetwork/ Gene network.] A much larger and thus more complicated/confusing repo. They are looking for help/contributers 
GitHub: [https://github.com/bioinform The Bioinformatics Repository.] Different repos, various languages. 


== Subjects covered ==
Hands-on addition to a code base,

== Exercises to be handed in ==
There are going to be only one exercise. You have the project, and the exercise will be big. 
Clone Anders Gorm's repo: ''sequencelib'' and study it. 
'''Make it able to read FASTQ files.''' 
This includes changing the Seqfile class, adding a new Fastqfilehandle class, and understanding the Sequence class really well. Most likely other stuff. 
Of course, you are using Git to handle your changes. You might make some kind of limitation somewhere (f.ex. do not implement reading form stdin) or maybe generator,
as FASTQ files get really big and can't all be in memory. Also, FASTQ are often gzipped - it is nice to read them directly from the gzip file. 
You don't know FASTQ format? - look it up - this is supposed to be a "real world problem". You don't get much help.

== Exercises for extra practice ==

Changing existing code base

2026-05-04T10:57:17Z

WikiSysop: /* Opportunity */

__NOTOC__
{| width=500 style="font-size: 10px; float:right; margin-left: 10px; margin-top: -56px;"
|Previous: [[Runtime evaluation]]
|Next: [[Last words]]
|}
== Opportunity ==
PDF: [https://teaching.healthtech.dtu.dk/material/22118/RNA-editing_Masterproject.pdf RNA Editing] A Master project. Contact Greg, grinos@dtu.dk

== Required course material for the lesson ==
GitHub: [https://github.com/agormp Professor Anders Gorm Pedersen's repositories.] Used in teaching this week. 
GitHub: [https://github.com/genenetwork/ Gene network.] A much larger and thus more complicated/confusing repo. They are looking for help/contributers 
GitHub: [https://github.com/bioinform The Bioinformatics Repository.] Different repos, various languages. 


== Subjects covered ==
Hands-on addition to a code base,

== Exercises to be handed in ==
There are going to be only one exercise. You have the project, and the exercise will be big. 
Clone Anders Gorm's repo: ''sequencelib'' and study it. 
'''Make it able to read FASTQ files.''' 
This includes changing the Seqfile class, adding a new Fastqfilehandle class, and understanding the Sequence class really well. 
Of course, you are using Git to handle your changes. You might make some kind of limitation somewhere or maybe generator,
as FASTQ files get really big and can't all be in memory. Also, FASTQ are often gzipped - it is nice to read them directly from the gzip file. 
You don't know FASTQ format? - look it up - this is supposed to be a "real world problem". You don't get much help.

== Exercises for extra practice ==

Changing existing code base

2026-05-04T09:52:21Z

WikiSysop:

__NOTOC__
{| width=500 style="font-size: 10px; float:right; margin-left: 10px; margin-top: -56px;"
|Previous: [[Runtime evaluation]]
|Next: [[Last words]]
|}
== Opportunity ==
PDF: [https://teaching.healthtech.dtu.dk/material/22118/RNA-editing_Masterproject.pdf RNA Editing] A Master project.

== Required course material for the lesson ==
GitHub: [https://github.com/agormp Professor Anders Gorm Pedersen's repositories.] Used in teaching this week. 
GitHub: [https://github.com/genenetwork/ Gene network.] A much larger and thus more complicated/confusing repo. They are looking for help/contributers 
GitHub: [https://github.com/bioinform The Bioinformatics Repository.] Different repos, various languages. 


== Subjects covered ==
Hands-on addition to a code base,

== Exercises to be handed in ==
There are going to be only one exercise. You have the project, and the exercise will be big. 
Clone Anders Gorm's repo: ''sequencelib'' and study it. 
'''Make it able to read FASTQ files.''' 
This includes changing the Seqfile class, adding a new Fastqfilehandle class, and understanding the Sequence class really well. 
Of course, you are using Git to handle your changes. You might make some kind of limitation somewhere or maybe generator,
as FASTQ files get really big and can't all be in memory. Also, FASTQ are often gzipped - it is nice to read them directly from the gzip file. 
You don't know FASTQ format? - look it up - this is supposed to be a "real world problem". You don't get much help.

== Exercises for extra practice ==

Changing existing code base

2026-04-30T13:48:14Z

WikiSysop: /* Required course material for the lesson */

__NOTOC__
{| width=500 style="font-size: 10px; float:right; margin-left: 10px; margin-top: -56px;"
|Previous: [[Runtime evaluation]]
|Next: [[Last words]]
|}
== Required course material for the lesson ==
GitHub: [https://github.com/agormp Professor Anders Gorm Pedersen's repositories.] Used in teaching this week. 
GitHub: [https://github.com/genenetwork/ Gene network.] A much larger and thus more complicated/confusing repo. They are looking for help/contributers 
GitHub: [https://github.com/bioinform The Bioinformatics Repository.] Different repos, various languages. 


== Subjects covered ==
Hands-on addition to a code base,

== Exercises to be handed in ==
There are going to be only one exercise. You have the project, and the exercise will be big. 
Clone Anders Gorm's repo: ''sequencelib'' and study it. 
'''Make it able to read FASTQ files.''' 
This includes changing the Seqfile class, adding a new Fastqfilehandle class, and understanding the Sequence class really well. 
Of course, you are using Git to handle your changes. You might make some kind of limitation somewhere or maybe generator,
as FASTQ files get really big and can't all be in memory. Also, FASTQ are often gzipped - it is nice to read them directly from the gzip file. 
You don't know FASTQ format? - look it up - this is supposed to be a "real world problem". You don't get much help.

== Exercises for extra practice ==

Changing existing code base

2026-04-30T13:42:41Z

WikiSysop: /* Exercises to be handed in */

__NOTOC__
{| width=500 style="font-size: 10px; float:right; margin-left: 10px; margin-top: -56px;"
|Previous: [[Runtime evaluation]]
|Next: [[Last words]]
|}
== Required course material for the lesson ==
GitHub: [https://github.com/agormp Professor Anders Gorm Pedersen's repositories.] Used in teaching this week. 
GitHub: [https://github.com/genenetwork/ Gene network.] A much larger and thus more complicated/confusing repo. 
GitHub: [https://github.com/bioinform The Bioinformatics Repository.] Different repos, various languages. 


== Subjects covered ==
Hands-on addition to a code base,

== Exercises to be handed in ==
There are going to be only one exercise. You have the project, and the exercise will be big. 
Clone Anders Gorm's repo: ''sequencelib'' and study it. 
'''Make it able to read FASTQ files.''' 
This includes changing the Seqfile class, adding a new Fastqfilehandle class, and understanding the Sequence class really well. 
Of course, you are using Git to handle your changes. You might make some kind of limitation somewhere or maybe generator,
as FASTQ files get really big and can't all be in memory. Also, FASTQ are often gzipped - it is nice to read them directly from the gzip file. 
You don't know FASTQ format? - look it up - this is supposed to be a "real world problem". You don't get much help.

== Exercises for extra practice ==

Changing existing code base

2026-04-30T12:28:58Z

WikiSysop: /* Exercises to be handed in */

Changing existing code base

2026-04-30T12:22:09Z

WikiSysop:

Changing existing code base

2026-04-30T12:20:58Z

WikiSysop: Created page with "__NOTOC__ {| width=500 style="font-size: 10px; float:right; margin-left: 10px; margin-top: -56px;" |Previous: Runtime evauation |Next: Last words |} == Required course material for the lesson == GitHub: [https://github.com/agormp Professor Anders Gorm Pedersen's repositories.] Used in teaching this week. GitHub: [https://github.com/genenetwork/ Gene network.] A much larger and thus more complicated/confusing repo. GitHub: [https://github.com/bioinform Th..."

__NOTOC__
{| width=500 style="font-size: 10px; float:right; margin-left: 10px; margin-top: -56px;"
|Previous: [[Runtime evauation]]
|Next: [[Last words]]
|}
== Required course material for the lesson ==
GitHub: [https://github.com/agormp Professor Anders Gorm Pedersen's repositories.] Used in teaching this week. 
GitHub: [https://github.com/genenetwork/ Gene network.] A much larger and thus more complicated/confusing repo. 
GitHub: [https://github.com/bioinform The Bioinformatics Repository.] Different repos, various languages. 


== Subjects covered ==
Hands-on addition to a code base,

== Exercises to be handed in ==
There are no exercises for this lecture - or the rest of the course

== Exercises for extra practice ==

Last words

2026-04-30T12:05:31Z

WikiSysop: /* Required course material for the lesson */

__NOTOC__
{| width=500 style="font-size: 10px; float:right; margin-left: 10px; margin-top: -56px;"
|Previous: [[Changing existing code base]]
|Next: [[Programme]]
|}
== Required course material for the lesson ==
Powerpoint: [https://teaching.healthtech.dtu.dk/material/22118/22118_05-MemoryManagement.ppt Memory management]. 
Powerpoint: [https://teaching.healthtech.dtu.dk/material/22118/22118_13-LastWords.ppt Last words] 
Guides: [https://github.com/evanpeikon/Bioinformatics_Toolkit Bioinformatics Toolkit by Evan Peikon.] Strong recommendation for anyone who want to up their skills. 
Guides: [https://github.com/harvardinformatics/learning-bioinformatics-at-home Learning Bioinformatics at Home by Harvard Informatics Group.] A bit of a mixed bag. 
Projects: [https://github.com/zamirmehdi/Bioinformatics-Course Bioinformatics Course by Amirmehdi Zarrinnezhad.] Looking for more coding projects? 
Future: [https://www.biotecnika.org/2025/09/how-to-build-a-github-portfolio-in-bioinformatics-a-step-by-step-guide-for-beginners/ Build your Portfolio on GitHub.] A step by step guide.


== Subjects covered ==
Python Memory Management 
Course summery 
Standard libraries 
Third party libraries 
Optimization 
Further courses

== Exercises to be handed in ==
There are no exercises for this lecture - or the rest of the course

== Exercises for extra practice ==

Last words

2026-04-30T09:28:55Z

WikiSysop: /* Required course material for the lesson */

__NOTOC__
{| width=500 style="font-size: 10px; float:right; margin-left: 10px; margin-top: -56px;"
|Previous: [[Changing existing code base]]
|Next: [[Programme]]
|}
== Required course material for the lesson ==
Powerpoint: [https://teaching.healthtech.dtu.dk/material/22118/22118_05-MemoryManagement.ppt Memory management]. 
Powerpoint: [https://teaching.healthtech.dtu.dk/material/22118/22118_13-LastWords.ppt Last words] 
Guides: [https://github.com/evanpeikon/Bioinformatics_Toolkit Bioinformatics Toolkit by Evan Peikon.] Strong recommendation for anyone who want to up their skills. 
Guides: [https://github.com/harvardinformatics/learning-bioinformatics-at-home Learning Bioinformatics at Home by Harvard Informatics Group.] A bit of a mixed bag. 
Projects: [https://github.com/zamirmehdi/Bioinformatics-Course Bioinformatics Course by Amirmehdi Zarrinnezhad.] Looking for more coding projects? 


== Subjects covered ==
Python Memory Management 
Course summery 
Standard libraries 
Third party libraries 
Optimization 
Further courses

== Exercises to be handed in ==
There are no exercises for this lecture - or the rest of the course

== Exercises for extra practice ==

Last words

2026-04-30T09:24:21Z

WikiSysop: /* Required course material for the lesson */

__NOTOC__
{| width=500 style="font-size: 10px; float:right; margin-left: 10px; margin-top: -56px;"
|Previous: [[Changing existing code base]]
|Next: [[Programme]]
|}
== Required course material for the lesson ==
Powerpoint: [https://teaching.healthtech.dtu.dk/material/22118/22118_05-MemoryManagement.ppt Memory management]. 
Powerpoint: [https://teaching.healthtech.dtu.dk/material/22118/22118_13-LastWords.ppt Last words] 
Guides: [https://github.com/evanpeikon/Bioinformatics_Toolkit Bioinformatics Toolkit by Evan Peikon.] Strong recommendation for anyone who want to up their skills. 
Guides: [https://github.com/harvardinformatics/learning-bioinformatics-at-home Learning Bioinformatics at Home by Harvard Informatics Group.] A bit of a mixed bag. 


== Subjects covered ==
Python Memory Management 
Course summery 
Standard libraries 
Third party libraries 
Optimization 
Further courses

== Exercises to be handed in ==
There are no exercises for this lecture - or the rest of the course

== Exercises for extra practice ==

Last words

2026-04-30T09:13:00Z

WikiSysop: /* Required course material for the lesson */

Runtime evaluation

2026-04-27T12:21:05Z

WikiSysop: /* How to calculate Big O in the project */

__NOTOC__
{| width=500 style="font-size: 10px; float:right; margin-left: 10px; margin-top: -56px;"
|Previous: [[Intermediate unit test]]
|Next: [[Changing existing code base]]
|}
== Required course material for the lesson ==
Powerpoint: [https://teaching.healthtech.dtu.dk/material/22113/Python10-Runtime.pptx Runtime evaluation of algorithms] Old ppt, not so important 
Video: [https://panopto.dtu.dk/Panopto/Pages/Viewer.aspx?id=41edc89b-61a5-475d-84d0-af2701271b5d Runtime Analysis] See this first

== Subjects covered ==
Runtime evaluation of algorithms 
Big O notation

== Big O notation ==
When you "calculate" the running time of a program or an algorithm you write your result in the '''Big O''' notation. The running time is the complexity of the algorithm. The hardest part about Big O is understanding the concept - performing the actual calculation is rather easy in most cases. Especially since there is no real calculation to do, but mostly just analysis of the code.

== Some loosely explained theory ==
Any program is performing some operations when it is running. This could be addition of a number to a variable. It could be asking which number is the biggest or if two strings are identical. You have been programming; every statement is an operation.

Calculating Big O is estimating the number of operations. This is '''not''' the number of statements. Some statements are executed several times in loops. Big O is more similar to the accumulated number of times each statement has been executed during the run of the program. While it is possible to calculate this number exactly, given an input and given that randomness is not part of the program, then this is not necessary and very uninteresting and possibly difficult.

What is needed is an estimate that explains how the program's running time scales with the size of the input; Big O.
Very often - almost always - a program contains loops that loop over data. Let's take the program that calculates the average of a list/file of numbers as an example.

# pseudo code
open file
for each line in file
sum = sum + number(line)
increment(line_counter)
close file
print sum/line_counter

The opening and closing of the file is done once, likewise the printing of the sum. The summing is done once per number/line. This means the more numbers there are in the file, the more additions are made. It scales with the number of numbers. The line_counter is also incremented once per line, so that obviously also scale in the same way as the summing. 
To put this in Big O notation: O(1 + n + n + 1 + 1) = O(2n + 3). 
This expression is still too complex. The "small stuff" is eliminated, this means remove the constants. They don't tell much about how running time scales anyway. 
The final Big O notation: O(n), where n is the number of numbers. 
If you have a more complex Big O like: O(n*n + n), then the single n is thrown away as that is not important compared to n*n, so O(n*n) is the final result.

== A collecting of internet resources on Big O ==
[http://stackoverflow.com/questions/487258/what-is-a-plain-english-explanation-of-big-o-notation Big O in plain English] 
[http://rob-bell.net/2009/06/a-beginners-guide-to-big-o-notation/ A Beginner's Guide to Big O Notation] 
[https://www.interviewcake.com/big-o-notation-time-and-space-complexity Big O Notation] 
[http://bigocheatsheet.com/ Big-O Algorithm Complexity Cheat Sheet] 
[https://justin.abrah.ms/computer-science/big-o-notation-explained.html Big O notation explained] 
[https://justin.abrah.ms/computer-science/how-to-calculate-big-o.html How to calculate Big O] 
[https://www.youtube.com/watch?v=V6mKVRU1evU Big O notations - a youtube video] 

[http://en.wikipedia.org/wiki/Big_O_notation Wikipedia's entry on Big O] is particular useless. It is most likely correct, but impossible to understand. Don't go there for information unless you like pain.

If all you want to do is to measure how long your program takes to run in real time (seconds and minutes), then you should just use the '''time''' command in unix. Simply put it in front of your program.

# Normally you call your program like
./mypythonprogram.py fastafile
# To see how long it takes to execute, use
time ./mypythonprogram.py fastafile

== How to calculate Big O in the project ==
When a program or algorithm is small, then it is often trivial to perform this "calculation". In bigger pieces of software, you often need to be more systematic about it. Since we know that the loops are what matters in Big O, then keeping track of the loops in the software as comments is a great way of starting a system. In this example, I have a list of numbers where all must be multiplied in pairs and then summed. 
The code:
numbers = [2,3,5,7,11,13]
sum = 0
for i in range(len(numbers)-1):
for j in range(i+1, len(numbers)):
sum += numbers[i] * numbers[j]
print("Result:", sum)
I start adding a comment about Big O in the inner loop. I discard the minor issues, like in essence the loop is at most n-1 long, and minimum 1 long. The worst case is what we use in these situations.
numbers = [2,3,5,7,11,13]
sum = 0
for i in range(len(numbers)-1):
# O(n), where n is the number of numbers, worst case
for j in range(i+1, len(numbers):
sum += numbers[i] * numbers[j]
print("Result:", sum)
Then I add a Big O comment to the outer loop. Since I already have the Big O for the inner loop, it is easy.
numbers = [2,3,5,7,11,13]
sum = 0
# O(n*n), where n is the number of numbers
for i in range(len(numbers)-1):
# O(n), where n is the number of numbers, worst case
for j in range(i+1, len(numbers)):
sum += numbers[i] * numbers[j]
print("Result:", sum)
Now I have the result, O(n*n), easily argued and explainable. Shown directly in the code. I should add some logical reasoning, but I have a strong analysis in the code, which can support me.

== Exercises to be handed in ==
"Calculate" can mean many things here; Analyze, argue, explain, show, or even demonstrate. For some algorithms (not these) it even means "do a lot of math". The calculation must be convincingly explained based on reasoning. Just showing the result is insufficient. 
# Calculate Big O of exercise 2 in [[Solo git]]
# Calculate Big O of exercise 1 in [[Functions, namespace, memory management]]
# Calculate Big O of exercise 3 in [[Functions, namespace, memory management]]
# Calculate Big O of exercise 1 in [[Comprehension, generators, iteration]]
# Calculate Big O of exercise 3 in [[Comprehension, generators, iteration]]
# Calculate Big O of exercise 6 in [[Comprehension, generators, iteration]]
# Analyze the algorithm of [[QT clustering]] (see Details). Make an argument for what is the worst case running time in the described form. This will be hard. The "Add one point from your data set at a time in such a way that you extend the candidate cluster diameter the least" covers an algorithm that you must think up. You might benefit from making some simple pseudo code of the entire QT clustering algorithm.

== Exercises for extra practice ==

Runtime evaluation

2026-04-24T09:06:07Z

WikiSysop: /* Exercises to be handed in */

__NOTOC__
{| width=500 style="font-size: 10px; float:right; margin-left: 10px; margin-top: -56px;"
|Previous: [[Intermediate unit test]]
|Next: [[Changing existing code base]]
|}
== Required course material for the lesson ==
Powerpoint: [https://teaching.healthtech.dtu.dk/material/22113/Python10-Runtime.pptx Runtime evaluation of algorithms] Old ppt, not so important 
Video: [https://panopto.dtu.dk/Panopto/Pages/Viewer.aspx?id=41edc89b-61a5-475d-84d0-af2701271b5d Runtime Analysis] See this first

== Subjects covered ==
Runtime evaluation of algorithms 
Big O notation

== Big O notation ==
When you "calculate" the running time of a program or an algorithm you write your result in the '''Big O''' notation. The running time is the complexity of the algorithm. The hardest part about Big O is understanding the concept - performing the actual calculation is rather easy in most cases. Especially since there is no real calculation to do, but mostly just analysis of the code.

== Some loosely explained theory ==
Any program is performing some operations when it is running. This could be addition of a number to a variable. It could be asking which number is the biggest or if two strings are identical. You have been programming; every statement is an operation.

Calculating Big O is estimating the number of operations. This is '''not''' the number of statements. Some statements are executed several times in loops. Big O is more similar to the accumulated number of times each statement has been executed during the run of the program. While it is possible to calculate this number exactly, given an input and given that randomness is not part of the program, then this is not necessary and very uninteresting and possibly difficult.

What is needed is an estimate that explains how the program's running time scales with the size of the input; Big O.
Very often - almost always - a program contains loops that loop over data. Let's take the program that calculates the average of a list/file of numbers as an example.

# pseudo code
open file
for each line in file
sum = sum + number(line)
increment(line_counter)
close file
print sum/line_counter

The opening and closing of the file is done once, likewise the printing of the sum. The summing is done once per number/line. This means the more numbers there are in the file, the more additions are made. It scales with the number of numbers. The line_counter is also incremented once per line, so that obviously also scale in the same way as the summing. 
To put this in Big O notation: O(1 + n + n + 1 + 1) = O(2n + 3). 
This expression is still too complex. The "small stuff" is eliminated, this means remove the constants. They don't tell much about how running time scales anyway. 
The final Big O notation: O(n), where n is the number of numbers. 
If you have a more complex Big O like: O(n*n + n), then the single n is thrown away as that is not important compared to n*n, so O(n*n) is the final result.

== A collecting of internet resources on Big O ==
[http://stackoverflow.com/questions/487258/what-is-a-plain-english-explanation-of-big-o-notation Big O in plain English] 
[http://rob-bell.net/2009/06/a-beginners-guide-to-big-o-notation/ A Beginner's Guide to Big O Notation] 
[https://www.interviewcake.com/big-o-notation-time-and-space-complexity Big O Notation] 
[http://bigocheatsheet.com/ Big-O Algorithm Complexity Cheat Sheet] 
[https://justin.abrah.ms/computer-science/big-o-notation-explained.html Big O notation explained] 
[https://justin.abrah.ms/computer-science/how-to-calculate-big-o.html How to calculate Big O] 
[https://www.youtube.com/watch?v=V6mKVRU1evU Big O notations - a youtube video] 

[http://en.wikipedia.org/wiki/Big_O_notation Wikipedia's entry on Big O] is particular useless. It is most likely correct, but impossible to understand. Don't go there for information unless you like pain.

If all you want to do is to measure how long your program takes to run in real time (seconds and minutes), then you should just use the '''time''' command in unix. Simply put it in front of your program.

# Normally you call your program like
./mypythonprogram.py fastafile
# To see how long it takes to execute, use
time ./mypythonprogram.py fastafile

== How to calculate Big O in the project ==
When a program or algorithm is small, then it is often trivial to perform this "calculation". In bigger pieces of software, you often need to be more systematic about it. Since we know that the loops are what matters in Big O, then keeping track of the loops in the software as comments is a great way of starting a system. In this example, I have a list of numbers where all must be multiplied in pairs and then summed. 
The code:
numbers = [2,3,5,7,11,13]
sum = 0
for i in range(len(numbers)-1):
for j in (j+1, range(numbers)):
sum += numbers[i] * numbers[j]
print("Result:", sum)
I start adding a comment about Big O in the inner loop. I discard the minor issues, like in essence the loop is at most n-1 long, and minimum 1 long. The worst case is what we use in these situations.
numbers = [2,3,5,7,11,13]
sum = 0
for i in range(len(numbers)-1):
# O(n), where n is the number of numbers, worst case
for j in (j+1, range(numbers)):
sum += numbers[i] * numbers[j]
print("Result:", sum)
Then I add a Big O comment to the outer loop. Since I already have the Big O for the inner loop, it is easy.
numbers = [2,3,5,7,11,13]
sum = 0
# O(n*n), where n is the number of numbers
for i in range(len(numbers)-1):
# O(n), where n is the number of numbers, worst case
for j in (j+1, range(numbers)):
sum += numbers[i] * numbers[j]
print("Result:", sum)
Now I have the result, O(n*n), easily argued and explainable. Shown directly in the code. I should add some logical reasoning, but I have a strong analysis in the code, which can support me.

== Exercises to be handed in ==
"Calculate" can mean many things here; Analyze, argue, explain, show, or even demonstrate. For some algorithms (not these) it even means "do a lot of math". The calculation must be convincingly explained based on reasoning. Just showing the result is insufficient. 
# Calculate Big O of exercise 2 in [[Solo git]]
# Calculate Big O of exercise 1 in [[Functions, namespace, memory management]]
# Calculate Big O of exercise 3 in [[Functions, namespace, memory management]]
# Calculate Big O of exercise 1 in [[Comprehension, generators, iteration]]
# Calculate Big O of exercise 3 in [[Comprehension, generators, iteration]]
# Calculate Big O of exercise 6 in [[Comprehension, generators, iteration]]
# Analyze the algorithm of [[QT clustering]] (see Details). Make an argument for what is the worst case running time in the described form. This will be hard. The "Add one point from your data set at a time in such a way that you extend the candidate cluster diameter the least" covers an algorithm that you must think up. You might benefit from making some simple pseudo code of the entire QT clustering algorithm.

== Exercises for extra practice ==

Runtime evaluation

2026-04-24T09:03:48Z

WikiSysop: /* Exercises to be handed in */

__NOTOC__
{| width=500 style="font-size: 10px; float:right; margin-left: 10px; margin-top: -56px;"
|Previous: [[Intermediate unit test]]
|Next: [[Changing existing code base]]
|}
== Required course material for the lesson ==
Powerpoint: [https://teaching.healthtech.dtu.dk/material/22113/Python10-Runtime.pptx Runtime evaluation of algorithms] Old ppt, not so important 
Video: [https://panopto.dtu.dk/Panopto/Pages/Viewer.aspx?id=41edc89b-61a5-475d-84d0-af2701271b5d Runtime Analysis] See this first

== Subjects covered ==
Runtime evaluation of algorithms 
Big O notation

== Big O notation ==
When you "calculate" the running time of a program or an algorithm you write your result in the '''Big O''' notation. The running time is the complexity of the algorithm. The hardest part about Big O is understanding the concept - performing the actual calculation is rather easy in most cases. Especially since there is no real calculation to do, but mostly just analysis of the code.

== Some loosely explained theory ==
Any program is performing some operations when it is running. This could be addition of a number to a variable. It could be asking which number is the biggest or if two strings are identical. You have been programming; every statement is an operation.

Calculating Big O is estimating the number of operations. This is '''not''' the number of statements. Some statements are executed several times in loops. Big O is more similar to the accumulated number of times each statement has been executed during the run of the program. While it is possible to calculate this number exactly, given an input and given that randomness is not part of the program, then this is not necessary and very uninteresting and possibly difficult.

What is needed is an estimate that explains how the program's running time scales with the size of the input; Big O.
Very often - almost always - a program contains loops that loop over data. Let's take the program that calculates the average of a list/file of numbers as an example.

# pseudo code
open file
for each line in file
sum = sum + number(line)
increment(line_counter)
close file
print sum/line_counter

The opening and closing of the file is done once, likewise the printing of the sum. The summing is done once per number/line. This means the more numbers there are in the file, the more additions are made. It scales with the number of numbers. The line_counter is also incremented once per line, so that obviously also scale in the same way as the summing. 
To put this in Big O notation: O(1 + n + n + 1 + 1) = O(2n + 3). 
This expression is still too complex. The "small stuff" is eliminated, this means remove the constants. They don't tell much about how running time scales anyway. 
The final Big O notation: O(n), where n is the number of numbers. 
If you have a more complex Big O like: O(n*n + n), then the single n is thrown away as that is not important compared to n*n, so O(n*n) is the final result.

== A collecting of internet resources on Big O ==
[http://stackoverflow.com/questions/487258/what-is-a-plain-english-explanation-of-big-o-notation Big O in plain English] 
[http://rob-bell.net/2009/06/a-beginners-guide-to-big-o-notation/ A Beginner's Guide to Big O Notation] 
[https://www.interviewcake.com/big-o-notation-time-and-space-complexity Big O Notation] 
[http://bigocheatsheet.com/ Big-O Algorithm Complexity Cheat Sheet] 
[https://justin.abrah.ms/computer-science/big-o-notation-explained.html Big O notation explained] 
[https://justin.abrah.ms/computer-science/how-to-calculate-big-o.html How to calculate Big O] 
[https://www.youtube.com/watch?v=V6mKVRU1evU Big O notations - a youtube video] 

[http://en.wikipedia.org/wiki/Big_O_notation Wikipedia's entry on Big O] is particular useless. It is most likely correct, but impossible to understand. Don't go there for information unless you like pain.

If all you want to do is to measure how long your program takes to run in real time (seconds and minutes), then you should just use the '''time''' command in unix. Simply put it in front of your program.

# Normally you call your program like
./mypythonprogram.py fastafile
# To see how long it takes to execute, use
time ./mypythonprogram.py fastafile

== How to calculate Big O in the project ==
When a program or algorithm is small, then it is often trivial to perform this "calculation". In bigger pieces of software, you often need to be more systematic about it. Since we know that the loops are what matters in Big O, then keeping track of the loops in the software as comments is a great way of starting a system. In this example, I have a list of numbers where all must be multiplied in pairs and then summed. 
The code:
numbers = [2,3,5,7,11,13]
sum = 0
for i in range(len(numbers)-1):
for j in (j+1, range(numbers)):
sum += numbers[i] * numbers[j]
print("Result:", sum)
I start adding a comment about Big O in the inner loop. I discard the minor issues, like in essence the loop is at most n-1 long, and minimum 1 long. The worst case is what we use in these situations.
numbers = [2,3,5,7,11,13]
sum = 0
for i in range(len(numbers)-1):
# O(n), where n is the number of numbers, worst case
for j in (j+1, range(numbers)):
sum += numbers[i] * numbers[j]
print("Result:", sum)
Then I add a Big O comment to the outer loop. Since I already have the Big O for the inner loop, it is easy.
numbers = [2,3,5,7,11,13]
sum = 0
# O(n*n), where n is the number of numbers
for i in range(len(numbers)-1):
# O(n), where n is the number of numbers, worst case
for j in (j+1, range(numbers)):
sum += numbers[i] * numbers[j]
print("Result:", sum)
Now I have the result, O(n*n), easily argued and explainable. Shown directly in the code. I should add some logical reasoning, but I have a strong analysis in the code, which can support me.

== Exercises to be handed in ==
"Calculate" can mean many things here; Analyze, argue, explain, show, or even demonstrate. For some algorithms (not these) it even means "do a lot of math". The calculation must be convincingly explained based on reasoning. Just showing the result is insufficient. 
# Calculate Big O of exercise 2 in [[Solo git]]
# Calculate Big O of exercise 1 in [[Functions, namespace, memory management]]
# Calculate Big O of exercise 3 in [[Functions, namespace, memory management]]
# Calculate Big O of exercise 1 in [[Comprehension, generators, iteration]]
# Calculate Big O of exercise 3 in [[Comprehension, generators, iteration]]
# Calculate Big O of exercise 6 in [[Comprehension, generators, iteration]]
# Analyze the algorithm of [[QT clustering]] (see Details). Make an argument for what is the worst case running time in the described form. This will be hard. The "Add one point from your data set at a time in such a way that you extend the candidate cluster diameter the least" covers an algorithm that you must think up.

== Exercises for extra practice ==

Runtime evaluation

2026-04-24T08:57:41Z

WikiSysop: /* Exercises to be handed in */

__NOTOC__
{| width=500 style="font-size: 10px; float:right; margin-left: 10px; margin-top: -56px;"
|Previous: [[Intermediate unit test]]
|Next: [[Changing existing code base]]
|}
== Required course material for the lesson ==
Powerpoint: [https://teaching.healthtech.dtu.dk/material/22113/Python10-Runtime.pptx Runtime evaluation of algorithms] Old ppt, not so important 
Video: [https://panopto.dtu.dk/Panopto/Pages/Viewer.aspx?id=41edc89b-61a5-475d-84d0-af2701271b5d Runtime Analysis] See this first

== Subjects covered ==
Runtime evaluation of algorithms 
Big O notation

== Big O notation ==
When you "calculate" the running time of a program or an algorithm you write your result in the '''Big O''' notation. The running time is the complexity of the algorithm. The hardest part about Big O is understanding the concept - performing the actual calculation is rather easy in most cases. Especially since there is no real calculation to do, but mostly just analysis of the code.

== Some loosely explained theory ==
Any program is performing some operations when it is running. This could be addition of a number to a variable. It could be asking which number is the biggest or if two strings are identical. You have been programming; every statement is an operation.

Calculating Big O is estimating the number of operations. This is '''not''' the number of statements. Some statements are executed several times in loops. Big O is more similar to the accumulated number of times each statement has been executed during the run of the program. While it is possible to calculate this number exactly, given an input and given that randomness is not part of the program, then this is not necessary and very uninteresting and possibly difficult.

What is needed is an estimate that explains how the program's running time scales with the size of the input; Big O.
Very often - almost always - a program contains loops that loop over data. Let's take the program that calculates the average of a list/file of numbers as an example.

# pseudo code
open file
for each line in file
sum = sum + number(line)
increment(line_counter)
close file
print sum/line_counter

The opening and closing of the file is done once, likewise the printing of the sum. The summing is done once per number/line. This means the more numbers there are in the file, the more additions are made. It scales with the number of numbers. The line_counter is also incremented once per line, so that obviously also scale in the same way as the summing. 
To put this in Big O notation: O(1 + n + n + 1 + 1) = O(2n + 3). 
This expression is still too complex. The "small stuff" is eliminated, this means remove the constants. They don't tell much about how running time scales anyway. 
The final Big O notation: O(n), where n is the number of numbers. 
If you have a more complex Big O like: O(n*n + n), then the single n is thrown away as that is not important compared to n*n, so O(n*n) is the final result.

== A collecting of internet resources on Big O ==
[http://stackoverflow.com/questions/487258/what-is-a-plain-english-explanation-of-big-o-notation Big O in plain English] 
[http://rob-bell.net/2009/06/a-beginners-guide-to-big-o-notation/ A Beginner's Guide to Big O Notation] 
[https://www.interviewcake.com/big-o-notation-time-and-space-complexity Big O Notation] 
[http://bigocheatsheet.com/ Big-O Algorithm Complexity Cheat Sheet] 
[https://justin.abrah.ms/computer-science/big-o-notation-explained.html Big O notation explained] 
[https://justin.abrah.ms/computer-science/how-to-calculate-big-o.html How to calculate Big O] 
[https://www.youtube.com/watch?v=V6mKVRU1evU Big O notations - a youtube video] 

[http://en.wikipedia.org/wiki/Big_O_notation Wikipedia's entry on Big O] is particular useless. It is most likely correct, but impossible to understand. Don't go there for information unless you like pain.

If all you want to do is to measure how long your program takes to run in real time (seconds and minutes), then you should just use the '''time''' command in unix. Simply put it in front of your program.

# Normally you call your program like
./mypythonprogram.py fastafile
# To see how long it takes to execute, use
time ./mypythonprogram.py fastafile

== How to calculate Big O in the project ==
When a program or algorithm is small, then it is often trivial to perform this "calculation". In bigger pieces of software, you often need to be more systematic about it. Since we know that the loops are what matters in Big O, then keeping track of the loops in the software as comments is a great way of starting a system. In this example, I have a list of numbers where all must be multiplied in pairs and then summed. 
The code:
numbers = [2,3,5,7,11,13]
sum = 0
for i in range(len(numbers)-1):
for j in (j+1, range(numbers)):
sum += numbers[i] * numbers[j]
print("Result:", sum)
I start adding a comment about Big O in the inner loop. I discard the minor issues, like in essence the loop is at most n-1 long, and minimum 1 long. The worst case is what we use in these situations.
numbers = [2,3,5,7,11,13]
sum = 0
for i in range(len(numbers)-1):
# O(n), where n is the number of numbers, worst case
for j in (j+1, range(numbers)):
sum += numbers[i] * numbers[j]
print("Result:", sum)
Then I add a Big O comment to the outer loop. Since I already have the Big O for the inner loop, it is easy.
numbers = [2,3,5,7,11,13]
sum = 0
# O(n*n), where n is the number of numbers
for i in range(len(numbers)-1):
# O(n), where n is the number of numbers, worst case
for j in (j+1, range(numbers)):
sum += numbers[i] * numbers[j]
print("Result:", sum)
Now I have the result, O(n*n), easily argued and explainable. Shown directly in the code. I should add some logical reasoning, but I have a strong analysis in the code, which can support me.

== Exercises to be handed in ==
"Calculate" can mean many things here; Analyze, argue, explain, show, or even demonstrate. For some algorithms (not these) it even means "do a lot of math". The calculation must be convincingly explained based on reasoning. Just showing the result is insufficient. 
# Calculate Big O of exercise 2 in [[Solo git]]
# Calculate Big O of exercise 1 in [[Functions, namespace, memory management]]
# Calculate Big O of exercise 3 in [[Functions, namespace, memory management]]
# Calculate Big O of exercise 1 in [[Comprehension, generators, iteration]]
# Calculate Big O of exercise 3 in [[Comprehension, generators, iteration]]
# Calculate Big O of exercise 6 in [[Comprehension, generators, iteration]]
# Analyze the algorithm of [[QT clustering]] (see Details). Make an argument for why it is worst case O(x^5) in the described form.

== Exercises for extra practice ==

Runtime evaluation

2026-04-24T08:56:44Z

WikiSysop: /* Exercises to be handed in */

__NOTOC__
{| width=500 style="font-size: 10px; float:right; margin-left: 10px; margin-top: -56px;"
|Previous: [[Intermediate unit test]]
|Next: [[Changing existing code base]]
|}
== Required course material for the lesson ==
Powerpoint: [https://teaching.healthtech.dtu.dk/material/22113/Python10-Runtime.pptx Runtime evaluation of algorithms] Old ppt, not so important 
Video: [https://panopto.dtu.dk/Panopto/Pages/Viewer.aspx?id=41edc89b-61a5-475d-84d0-af2701271b5d Runtime Analysis] See this first

== Subjects covered ==
Runtime evaluation of algorithms 
Big O notation

== Big O notation ==
When you "calculate" the running time of a program or an algorithm you write your result in the '''Big O''' notation. The running time is the complexity of the algorithm. The hardest part about Big O is understanding the concept - performing the actual calculation is rather easy in most cases. Especially since there is no real calculation to do, but mostly just analysis of the code.

== Some loosely explained theory ==
Any program is performing some operations when it is running. This could be addition of a number to a variable. It could be asking which number is the biggest or if two strings are identical. You have been programming; every statement is an operation.

Calculating Big O is estimating the number of operations. This is '''not''' the number of statements. Some statements are executed several times in loops. Big O is more similar to the accumulated number of times each statement has been executed during the run of the program. While it is possible to calculate this number exactly, given an input and given that randomness is not part of the program, then this is not necessary and very uninteresting and possibly difficult.

What is needed is an estimate that explains how the program's running time scales with the size of the input; Big O.
Very often - almost always - a program contains loops that loop over data. Let's take the program that calculates the average of a list/file of numbers as an example.

# pseudo code
open file
for each line in file
sum = sum + number(line)
increment(line_counter)
close file
print sum/line_counter

The opening and closing of the file is done once, likewise the printing of the sum. The summing is done once per number/line. This means the more numbers there are in the file, the more additions are made. It scales with the number of numbers. The line_counter is also incremented once per line, so that obviously also scale in the same way as the summing. 
To put this in Big O notation: O(1 + n + n + 1 + 1) = O(2n + 3). 
This expression is still too complex. The "small stuff" is eliminated, this means remove the constants. They don't tell much about how running time scales anyway. 
The final Big O notation: O(n), where n is the number of numbers. 
If you have a more complex Big O like: O(n*n + n), then the single n is thrown away as that is not important compared to n*n, so O(n*n) is the final result.

== A collecting of internet resources on Big O ==
[http://stackoverflow.com/questions/487258/what-is-a-plain-english-explanation-of-big-o-notation Big O in plain English] 
[http://rob-bell.net/2009/06/a-beginners-guide-to-big-o-notation/ A Beginner's Guide to Big O Notation] 
[https://www.interviewcake.com/big-o-notation-time-and-space-complexity Big O Notation] 
[http://bigocheatsheet.com/ Big-O Algorithm Complexity Cheat Sheet] 
[https://justin.abrah.ms/computer-science/big-o-notation-explained.html Big O notation explained] 
[https://justin.abrah.ms/computer-science/how-to-calculate-big-o.html How to calculate Big O] 
[https://www.youtube.com/watch?v=V6mKVRU1evU Big O notations - a youtube video] 

[http://en.wikipedia.org/wiki/Big_O_notation Wikipedia's entry on Big O] is particular useless. It is most likely correct, but impossible to understand. Don't go there for information unless you like pain.

If all you want to do is to measure how long your program takes to run in real time (seconds and minutes), then you should just use the '''time''' command in unix. Simply put it in front of your program.

# Normally you call your program like
./mypythonprogram.py fastafile
# To see how long it takes to execute, use
time ./mypythonprogram.py fastafile

== How to calculate Big O in the project ==
When a program or algorithm is small, then it is often trivial to perform this "calculation". In bigger pieces of software, you often need to be more systematic about it. Since we know that the loops are what matters in Big O, then keeping track of the loops in the software as comments is a great way of starting a system. In this example, I have a list of numbers where all must be multiplied in pairs and then summed. 
The code:
numbers = [2,3,5,7,11,13]
sum = 0
for i in range(len(numbers)-1):
for j in (j+1, range(numbers)):
sum += numbers[i] * numbers[j]
print("Result:", sum)
I start adding a comment about Big O in the inner loop. I discard the minor issues, like in essence the loop is at most n-1 long, and minimum 1 long. The worst case is what we use in these situations.
numbers = [2,3,5,7,11,13]
sum = 0
for i in range(len(numbers)-1):
# O(n), where n is the number of numbers, worst case
for j in (j+1, range(numbers)):
sum += numbers[i] * numbers[j]
print("Result:", sum)
Then I add a Big O comment to the outer loop. Since I already have the Big O for the inner loop, it is easy.
numbers = [2,3,5,7,11,13]
sum = 0
# O(n*n), where n is the number of numbers
for i in range(len(numbers)-1):
# O(n), where n is the number of numbers, worst case
for j in (j+1, range(numbers)):
sum += numbers[i] * numbers[j]
print("Result:", sum)
Now I have the result, O(n*n), easily argued and explainable. Shown directly in the code. I should add some logical reasoning, but I have a strong analysis in the code, which can support me.

== Exercises to be handed in ==
"Calculate" can mean many things here; Analyze, argue, explain, show, or even demonstrate. For some algorithms (not these) it even means "do a lot of math". The calculation must be convincingly explained based on reasoning. Just showing the result is insufficient. 
# Calculate Big O of exercise 2 in [[Solo git]]
# Calculate Big O of exercise 1 in [[Functions, namespace, memory management]]
# Calculate Big O of exercise 3 in [[Functions, namespace, memory management]]
# Calculate Big O of exercise 1 in [[Comprehension, generators, iteration]]
# Calculate Big O of exercise 3 in [[Comprehension, generators, iteration]]
# Calculate Big O of exercise 6 in [[Comprehension, generators, iteration]]
# Analyze the algorithm of [[QT clustering]] (see Details). Make an argument for why it is worst case O(x^7) in the described form.

== Exercises for extra practice ==

Runtime evaluation

2026-04-24T08:55:29Z

WikiSysop: /* Exercises to be handed in */

__NOTOC__
{| width=500 style="font-size: 10px; float:right; margin-left: 10px; margin-top: -56px;"
|Previous: [[Intermediate unit test]]
|Next: [[Changing existing code base]]
|}
== Required course material for the lesson ==
Powerpoint: [https://teaching.healthtech.dtu.dk/material/22113/Python10-Runtime.pptx Runtime evaluation of algorithms] Old ppt, not so important 
Video: [https://panopto.dtu.dk/Panopto/Pages/Viewer.aspx?id=41edc89b-61a5-475d-84d0-af2701271b5d Runtime Analysis] See this first

== Subjects covered ==
Runtime evaluation of algorithms 
Big O notation

== Big O notation ==
When you "calculate" the running time of a program or an algorithm you write your result in the '''Big O''' notation. The running time is the complexity of the algorithm. The hardest part about Big O is understanding the concept - performing the actual calculation is rather easy in most cases. Especially since there is no real calculation to do, but mostly just analysis of the code.

== Some loosely explained theory ==
Any program is performing some operations when it is running. This could be addition of a number to a variable. It could be asking which number is the biggest or if two strings are identical. You have been programming; every statement is an operation.

Calculating Big O is estimating the number of operations. This is '''not''' the number of statements. Some statements are executed several times in loops. Big O is more similar to the accumulated number of times each statement has been executed during the run of the program. While it is possible to calculate this number exactly, given an input and given that randomness is not part of the program, then this is not necessary and very uninteresting and possibly difficult.

What is needed is an estimate that explains how the program's running time scales with the size of the input; Big O.
Very often - almost always - a program contains loops that loop over data. Let's take the program that calculates the average of a list/file of numbers as an example.

# pseudo code
open file
for each line in file
sum = sum + number(line)
increment(line_counter)
close file
print sum/line_counter

The opening and closing of the file is done once, likewise the printing of the sum. The summing is done once per number/line. This means the more numbers there are in the file, the more additions are made. It scales with the number of numbers. The line_counter is also incremented once per line, so that obviously also scale in the same way as the summing. 
To put this in Big O notation: O(1 + n + n + 1 + 1) = O(2n + 3). 
This expression is still too complex. The "small stuff" is eliminated, this means remove the constants. They don't tell much about how running time scales anyway. 
The final Big O notation: O(n), where n is the number of numbers. 
If you have a more complex Big O like: O(n*n + n), then the single n is thrown away as that is not important compared to n*n, so O(n*n) is the final result.

== A collecting of internet resources on Big O ==
[http://stackoverflow.com/questions/487258/what-is-a-plain-english-explanation-of-big-o-notation Big O in plain English] 
[http://rob-bell.net/2009/06/a-beginners-guide-to-big-o-notation/ A Beginner's Guide to Big O Notation] 
[https://www.interviewcake.com/big-o-notation-time-and-space-complexity Big O Notation] 
[http://bigocheatsheet.com/ Big-O Algorithm Complexity Cheat Sheet] 
[https://justin.abrah.ms/computer-science/big-o-notation-explained.html Big O notation explained] 
[https://justin.abrah.ms/computer-science/how-to-calculate-big-o.html How to calculate Big O] 
[https://www.youtube.com/watch?v=V6mKVRU1evU Big O notations - a youtube video] 

[http://en.wikipedia.org/wiki/Big_O_notation Wikipedia's entry on Big O] is particular useless. It is most likely correct, but impossible to understand. Don't go there for information unless you like pain.

If all you want to do is to measure how long your program takes to run in real time (seconds and minutes), then you should just use the '''time''' command in unix. Simply put it in front of your program.

# Normally you call your program like
./mypythonprogram.py fastafile
# To see how long it takes to execute, use
time ./mypythonprogram.py fastafile

== How to calculate Big O in the project ==
When a program or algorithm is small, then it is often trivial to perform this "calculation". In bigger pieces of software, you often need to be more systematic about it. Since we know that the loops are what matters in Big O, then keeping track of the loops in the software as comments is a great way of starting a system. In this example, I have a list of numbers where all must be multiplied in pairs and then summed. 
The code:
numbers = [2,3,5,7,11,13]
sum = 0
for i in range(len(numbers)-1):
for j in (j+1, range(numbers)):
sum += numbers[i] * numbers[j]
print("Result:", sum)
I start adding a comment about Big O in the inner loop. I discard the minor issues, like in essence the loop is at most n-1 long, and minimum 1 long. The worst case is what we use in these situations.
numbers = [2,3,5,7,11,13]
sum = 0
for i in range(len(numbers)-1):
# O(n), where n is the number of numbers, worst case
for j in (j+1, range(numbers)):
sum += numbers[i] * numbers[j]
print("Result:", sum)
Then I add a Big O comment to the outer loop. Since I already have the Big O for the inner loop, it is easy.
numbers = [2,3,5,7,11,13]
sum = 0
# O(n*n), where n is the number of numbers
for i in range(len(numbers)-1):
# O(n), where n is the number of numbers, worst case
for j in (j+1, range(numbers)):
sum += numbers[i] * numbers[j]
print("Result:", sum)
Now I have the result, O(n*n), easily argued and explainable. Shown directly in the code. I should add some logical reasoning, but I have a strong analysis in the code, which can support me.

== Exercises to be handed in ==
"Calculate" can mean many things here; Analyze, argue, explain, show, or even demonstrate. For some algorithms (not these) it even means "do a lot of math". The calculation must be convincingly explained based on reasoning. Just showing the result is insufficient. 
# Calculate Big O of exercise 2 in [[Solo git]]
# Calculate Big O of exercise 1 in [[Functions, namespace, memory management]]
# Calculate Big O of exercise 3 in [[Functions, namespace, memory management]]
# Calculate Big O of exercise 1 in [[Comprehension, generators, iteration]]
# Calculate Big O of exercise 3 in [[Comprehension, generators, iteration]]
# Calculate Big O of exercise 6 in [[Comprehension, generators, iteration]]
# Analyze the algorithm of [[QT clustering]] (see Details). Make an argument for why it is worst case O(x^7).

== Exercises for extra practice ==

Runtime evaluation

2026-04-24T08:48:59Z

WikiSysop: /* Exercises to be handed in */

__NOTOC__
{| width=500 style="font-size: 10px; float:right; margin-left: 10px; margin-top: -56px;"
|Previous: [[Intermediate unit test]]
|Next: [[Changing existing code base]]
|}
== Required course material for the lesson ==
Powerpoint: [https://teaching.healthtech.dtu.dk/material/22113/Python10-Runtime.pptx Runtime evaluation of algorithms] Old ppt, not so important 
Video: [https://panopto.dtu.dk/Panopto/Pages/Viewer.aspx?id=41edc89b-61a5-475d-84d0-af2701271b5d Runtime Analysis] See this first

== Subjects covered ==
Runtime evaluation of algorithms 
Big O notation

== Big O notation ==
When you "calculate" the running time of a program or an algorithm you write your result in the '''Big O''' notation. The running time is the complexity of the algorithm. The hardest part about Big O is understanding the concept - performing the actual calculation is rather easy in most cases. Especially since there is no real calculation to do, but mostly just analysis of the code.

== Some loosely explained theory ==
Any program is performing some operations when it is running. This could be addition of a number to a variable. It could be asking which number is the biggest or if two strings are identical. You have been programming; every statement is an operation.

Calculating Big O is estimating the number of operations. This is '''not''' the number of statements. Some statements are executed several times in loops. Big O is more similar to the accumulated number of times each statement has been executed during the run of the program. While it is possible to calculate this number exactly, given an input and given that randomness is not part of the program, then this is not necessary and very uninteresting and possibly difficult.

What is needed is an estimate that explains how the program's running time scales with the size of the input; Big O.
Very often - almost always - a program contains loops that loop over data. Let's take the program that calculates the average of a list/file of numbers as an example.

# pseudo code
open file
for each line in file
sum = sum + number(line)
increment(line_counter)
close file
print sum/line_counter

The opening and closing of the file is done once, likewise the printing of the sum. The summing is done once per number/line. This means the more numbers there are in the file, the more additions are made. It scales with the number of numbers. The line_counter is also incremented once per line, so that obviously also scale in the same way as the summing. 
To put this in Big O notation: O(1 + n + n + 1 + 1) = O(2n + 3). 
This expression is still too complex. The "small stuff" is eliminated, this means remove the constants. They don't tell much about how running time scales anyway. 
The final Big O notation: O(n), where n is the number of numbers. 
If you have a more complex Big O like: O(n*n + n), then the single n is thrown away as that is not important compared to n*n, so O(n*n) is the final result.

== A collecting of internet resources on Big O ==
[http://stackoverflow.com/questions/487258/what-is-a-plain-english-explanation-of-big-o-notation Big O in plain English] 
[http://rob-bell.net/2009/06/a-beginners-guide-to-big-o-notation/ A Beginner's Guide to Big O Notation] 
[https://www.interviewcake.com/big-o-notation-time-and-space-complexity Big O Notation] 
[http://bigocheatsheet.com/ Big-O Algorithm Complexity Cheat Sheet] 
[https://justin.abrah.ms/computer-science/big-o-notation-explained.html Big O notation explained] 
[https://justin.abrah.ms/computer-science/how-to-calculate-big-o.html How to calculate Big O] 
[https://www.youtube.com/watch?v=V6mKVRU1evU Big O notations - a youtube video] 

[http://en.wikipedia.org/wiki/Big_O_notation Wikipedia's entry on Big O] is particular useless. It is most likely correct, but impossible to understand. Don't go there for information unless you like pain.

If all you want to do is to measure how long your program takes to run in real time (seconds and minutes), then you should just use the '''time''' command in unix. Simply put it in front of your program.

# Normally you call your program like
./mypythonprogram.py fastafile
# To see how long it takes to execute, use
time ./mypythonprogram.py fastafile

== How to calculate Big O in the project ==
When a program or algorithm is small, then it is often trivial to perform this "calculation". In bigger pieces of software, you often need to be more systematic about it. Since we know that the loops are what matters in Big O, then keeping track of the loops in the software as comments is a great way of starting a system. In this example, I have a list of numbers where all must be multiplied in pairs and then summed. 
The code:
numbers = [2,3,5,7,11,13]
sum = 0
for i in range(len(numbers)-1):
for j in (j+1, range(numbers)):
sum += numbers[i] * numbers[j]
print("Result:", sum)
I start adding a comment about Big O in the inner loop. I discard the minor issues, like in essence the loop is at most n-1 long, and minimum 1 long. The worst case is what we use in these situations.
numbers = [2,3,5,7,11,13]
sum = 0
for i in range(len(numbers)-1):
# O(n), where n is the number of numbers, worst case
for j in (j+1, range(numbers)):
sum += numbers[i] * numbers[j]
print("Result:", sum)
Then I add a Big O comment to the outer loop. Since I already have the Big O for the inner loop, it is easy.
numbers = [2,3,5,7,11,13]
sum = 0
# O(n*n), where n is the number of numbers
for i in range(len(numbers)-1):
# O(n), where n is the number of numbers, worst case
for j in (j+1, range(numbers)):
sum += numbers[i] * numbers[j]
print("Result:", sum)
Now I have the result, O(n*n), easily argued and explainable. Shown directly in the code. I should add some logical reasoning, but I have a strong analysis in the code, which can support me.

== Exercises to be handed in ==
"Calculate" can mean many things here; Analyze, argue, explain, show, or even demonstrate. For some algorithms (not these) it even means "do a lot of math". The calculation must be convincingly explained based on reasoning. Just showing the result is insufficient. 
# Calculate Big O of exercise 2 in [[Solo git]]
# Calculate Big O of exercise 1 in [[Functions, namespace, memory management]]
# Calculate Big O of exercise 3 in [[Functions, namespace, memory management]]
# Calculate Big O of exercise 1 in [[Comprehension, generators, iteration]]
# Calculate Big O of exercise 3 in [[Comprehension, generators, iteration]]
# Calculate Big O of exercise 6 in [[Comprehension, generators, iteration]]

== Exercises for extra practice ==

Intermediate unit test

2026-04-19T18:15:44Z

WikiSysop: /* Exercises to be handed in */

__NOTOC__
{| width=500 style="font-size: 10px; float:right; margin-left: 10px; margin-top: -56px;"
|Previous: [[Beginning unit test]]
|Next: [[Runtime evaluation]]
|}
== Required course material for the lesson ==
Powerpoint: [https://teaching.healthtech.dtu.dk/material/22118/22118_09-Testing.ppt Testing] 
Online: [https://docs.pytest.org/ pytest documentation] 
Resource: [[Unit test - start of reverse polish notation class]] 
Blog: [https://www.joelonsoftware.com/2000/04/30/top-five-wrong-reasons-you-dont-have-testers/ On testing], by the founder of StackExchange. 

== Subjects covered ==
Unit test using pytest framework. 
Files, test data 
Setting up real projects 

== Exercises to be handed in ==
You should make a special folder for the exercises. I will refer to my special folder as ''unittest'' in these exercises. You will also see some ''__pycache__'' folders appear in places. This is Pythons cache for "compiled" programs. It is safe to ignore and also to delete, because it may become outdated.
# Follow the file structure of having a ''code'' (or ''src'') folder for programs, a ''test'' folder for tests, and now a ''testdata'' folder for files containing test data. Now make unit tests and appropriate test data files for your '''fasta''' class from last week. In this exercise you just need to make unit test for the method '''load'''. You need to hand in both tests and test data. 
# Add unit tests for the method '''save''' in your '''fasta''' class. Hand in same way as above. 
# Add unit tests for the method '''delete''' in your '''fasta''' class. Use a fixture for setting up a test set for you deletion tests. Hand in same way as above. 
# Change your unit test setup of your fasta class to the package structure. That includes the correct folder structure, pyproject.toml and __init__.py file. 
I would not be surprised if you find errors in your '''fasta''' class based on these tests. I found flaws in my code.

== Exercises for extra practice ==
# Add unit tests for all methods in your '''fasta''' class. That will be a bit of work.

Intermediate unit test

2026-04-19T18:15:36Z

WikiSysop: /* Exercises to be handed in */

__NOTOC__
{| width=500 style="font-size: 10px; float:right; margin-left: 10px; margin-top: -56px;"
|Previous: [[Beginning unit test]]
|Next: [[Runtime evaluation]]
|}
== Required course material for the lesson ==
Powerpoint: [https://teaching.healthtech.dtu.dk/material/22118/22118_09-Testing.ppt Testing] 
Online: [https://docs.pytest.org/ pytest documentation] 
Resource: [[Unit test - start of reverse polish notation class]] 
Blog: [https://www.joelonsoftware.com/2000/04/30/top-five-wrong-reasons-you-dont-have-testers/ On testing], by the founder of StackExchange. 

== Subjects covered ==
Unit test using pytest framework. 
Files, test data 
Setting up real projects 

== Exercises to be handed in ==
You should make a special folder for the exercises. I will refer to my special folder as ''unittest'' in these exercises. You will also see some ''__pycache__'' folders appear in places. This is Pythons cache for "compiled" programs. It is safe to ignore and also to delete, because it may become outdated.
# Follow the file structure of having a ''code'' (or ''src'') folder for programs, a ''test'' folder for tests, and now a ''testdata'' folder for files containing test data. Now make unit tests and appropriate test data files for your '''fasta''' class from last week. In this exercise you just need to make unit test for the method '''load'''. You need to hand in both tests and test data. 
# Add unit tests for the method '''save''' in your '''fasta''' class. Hand in same way as above. 
# Add unit tests for the method '''delete''' in your '''fasta''' class. Use a fixture for setting up a test set for you deletion tests. Hand in same way as above. 
# Change your unit test setup of your fasta class to the package structure. That includes the correct folder structure, pyproject.toml and __init__.py file. br>
I would not be surprised if you find errors in your '''fasta''' class based on these tests. I found flaws in my code.

== Exercises for extra practice ==
# Add unit tests for all methods in your '''fasta''' class. That will be a bit of work.

Intermediate unit test

2026-04-19T17:58:41Z

WikiSysop: /* Exercises to be handed in */

__NOTOC__
{| width=500 style="font-size: 10px; float:right; margin-left: 10px; margin-top: -56px;"
|Previous: [[Beginning unit test]]
|Next: [[Runtime evaluation]]
|}
== Required course material for the lesson ==
Powerpoint: [https://teaching.healthtech.dtu.dk/material/22118/22118_09-Testing.ppt Testing] 
Online: [https://docs.pytest.org/ pytest documentation] 
Resource: [[Unit test - start of reverse polish notation class]] 
Blog: [https://www.joelonsoftware.com/2000/04/30/top-five-wrong-reasons-you-dont-have-testers/ On testing], by the founder of StackExchange. 

== Subjects covered ==
Unit test using pytest framework. 
Files, test data 
Setting up real projects 

== Exercises to be handed in ==
You should make a special folder for the exercises. I will refer to my special folder as ''unittest'' in these exercises. You will also see some ''__pycache__'' folders appear in places. This is Pythons cache for "compiled" programs. It is safe to ignore and also to delete, because it may become outdated.
# Follow the file structure of having a ''code'' (or ''src'') folder for programs, a ''test'' folder for tests, and now a ''testdata'' folder for files containing test data. Now make unit tests and appropriate test data files for your '''fasta''' class from last week. In this exercise you just need to make unit test for the method '''load'''. You need to hand in both tests and test data. 
# Add unit tests for the method '''save''' in your '''fasta''' class. Hand in same way as above. 
# Add unit tests for the method '''delete''' in your '''fasta''' class. Use a fixture for setting up a test set for you deletion tests. Hand in same way as above. 
# Change your unit test setup of your fasta class to the package structure. That includes the correct folder structure, pyproject.toml and __init__.py file.
I would not be surprised if you find errors in your '''fasta''' class based on these tests. I found flaws in my code.

== Exercises for extra practice ==
# Add unit tests for all methods in your '''fasta''' class. That will be a bit of work.

Beginning unit test

2026-04-14T16:37:28Z

WikiSysop: /* Exercises to be handed in */

__NOTOC__
{| width=500 style="font-size: 10px; float:right; margin-left: 10px; margin-top: -56px;"
|Previous: [[Intermediate classes]]
|Next: [[Intermediate unit test]]
|}
== Required course material for the lesson ==
Powerpoint: [https://teaching.healthtech.dtu.dk/material/22118/22118_09-Testing.ppt Testing] 
Online: [https://docs.pytest.org/ pytest documentation] 
Resource: [[Example code - Unit test]] 
Resource: [[Unit test - start of reverse polish notation class]] 

=== Installation of pytest ===
If you are using an anaconda python installation pytest is included. You can test in your python has pytest.
# On command line both should work or none
python3 -c "import pytest"
which pytest
# It is pretty clear if you fail. Success can be more obscure.
# Here is a fail test, so you can compare
python3 -c "import yptest"
which yptest
To install pytest, you need to be root/administrator.
# An install on a basic system
pip install -U pytest
# or maybe (depending on your system)
sudo pip install -U pytest
# Using ubuntu, which is also WSL in this situation, there is a package
apt install python3-pytest

== Subjects covered ==
Overview of test methods 
Unit test using pytest framework.

== Exercises to be handed in ==
You should make a special folder for the exercises. I will refer to my special folder as ''unittest'' in these exercises. You will also see some ''__pycache__'' folders appear in places. This is Pythons cache for "compiled" programs. It is safe to ignore and also to delete, because it may become outdated. 
In some of these exercise you need to hand in not just a single file, but multiple files in a folder hierarchy. Zip the folder structure for your entire solution folder. Make sure it is clear to see what exercise your code/data is solving. And learn to zip :-)
# Use your '''normalize''' function from exercise 3 in [[Functions, namespace, memory management]]. If you did not do so already, change it to use exceptions instead of '''sys.exit()''', when an error occurs. Now make simple unit tests for the following test cases: a list of positive numbers, a list of negative numbers, a list of integers, a list of mixed floats and integers, a single number in the list, empty list, a list with at least one non-number (string, list, set), a set containing numbers, and a dict where the keys are numbers. Get other ideas if you can. The '''normalize''' function and all test functions must be in one single file (''normalize_test.py'' in ''unittest''), which you can run ''pytest'' on. 
# Now remove the '''normalize''' function from ''normalize_test.py'' and put it in its own file ''normalize.py''. Import it from the ''normalize_test.py'' like '''from normalize import normalize'''. The first ''normalize'' is the name of the .py file, the second ''normalize'' is the name of your normalize function. Just run ''pytest'' (no file name) in the folder to check it works. It is more normal to have test and function separated. 
# Above we removed test code from function code by creating two files. Next, put the files in their own folder in ''unittest''. I would put my ''normalize.py'' in ''unittest/src'' and ''normalize_test.py'' in ''unittest/test''. This way there is a very clear separation between function and test. The problem is making sure the test code loads the function code. Do it wrong a couple of times - it is very instructive for how the search path works. Try to run the test from a different folder (unittest), like "pytest test/normalize_test.py" to see how vulnerable just using the path is. 
# You hopefully remember the '''MyMath''' class you made in exercise 1 & 2 in [[Beginning classes]]. Make a folder ''classes'' in your ''unittest/src'' folder and put the ''MyMath'' class in a file ''MyMath.py'' in ''unittest/src/classes''. Now make a unit test file ''MyMath_factorial_test.py'' in ''unittest/test'' that - surprise - tests your factorial method. Test it with at least these input: 12, 2, 1, 0, -1, 3.0, 3.4, "3", "3.1.", "ABC". Parametrize at least the tests that should succeed. Bonus for parametrizing the exceptions. 
# ''MyMath'' class also contains the ''supply'' method. Make unit tests for that method in the file ''unittest/test/MyMath_supply_test.py''. Make the "usual" tests, which are the same as you did in the first exercise. 
# Now make unit tests for the ''average'' method in '''MyMath'''. Make the tests in the file ''unittest/test/MyMath_average_test.py''. Notice how that interacts with the ''supply'' unit tests because ''average'' depends on correct working of ''supply''. Sometimes you won't even find the flaw in one method before you test another that depends on it. I am not going to tell you this time what unit tests you should make. You should know by now.

== Exercises for extra practice ==

Beginning unit test

2026-04-14T16:36:12Z

WikiSysop: /* Exercises to be handed in */

__NOTOC__
{| width=500 style="font-size: 10px; float:right; margin-left: 10px; margin-top: -56px;"
|Previous: [[Intermediate classes]]
|Next: [[Intermediate unit test]]
|}
== Required course material for the lesson ==
Powerpoint: [https://teaching.healthtech.dtu.dk/material/22118/22118_09-Testing.ppt Testing] 
Online: [https://docs.pytest.org/ pytest documentation] 
Resource: [[Example code - Unit test]] 
Resource: [[Unit test - start of reverse polish notation class]] 

=== Installation of pytest ===
If you are using an anaconda python installation pytest is included. You can test in your python has pytest.
# On command line both should work or none
python3 -c "import pytest"
which pytest
# It is pretty clear if you fail. Success can be more obscure.
# Here is a fail test, so you can compare
python3 -c "import yptest"
which yptest
To install pytest, you need to be root/administrator.
# An install on a basic system
pip install -U pytest
# or maybe (depending on your system)
sudo pip install -U pytest
# Using ubuntu, which is also WSL in this situation, there is a package
apt install python3-pytest

== Subjects covered ==
Overview of test methods 
Unit test using pytest framework.

== Exercises to be handed in ==
You should make a special folder for the exercises. I will refer to my special folder as ''unittest'' in these exercises. You will also see some ''__pycache__'' folders appear in places. This is Pythons cache for "compiled" programs. It is safe to ignore and also to delete, because it may become outdated. 
In some of these exercise you need to hand in not just a single file, but multiple files in a folder hierarchy. Zip the folder structure for your entire solution folder. Make sure it is clear to see what exercise your code/data is solving. And learn to zip :-)
# Use your '''normalize''' function from exercise 3 in [[Functions, namespace, memory management]]. If you did not do so already, change it to use exceptions instead of '''sys.exit()''', when an error occurs. Now make simple unit tests for the following test cases: a list of positive numbers, a list of negative numbers, a list of integers, a list of mixed floats and integers, a single number in the list, empty list, a list with at least one non-number (string, list, set), a set containing numbers, and a dict where the keys are numbers. Get other ideas if you can. The '''normalize''' function and all test functions must be in one single file (''normalize_test.py'' in ''unittest''), which you can run ''pytest'' on. 
# Now remove the '''normalize''' function from ''normalize_test.py'' and put it in its own file ''normalize.py''. Import it from the ''normalize_test.py'' like '''from normalize import normalize'''. The first ''normalize'' is the name of the .py file, the second ''normalize'' is the name of your normalize function. Just run ''pytest'' (no file name) in the folder to check it works. It is more normal to have test and function separated. 
# Above we removed test code from function code by creating two files. Next, put the files in their own folder in ''unittest''. I would put my ''normalize.py'' in ''unittest/src'' and ''normalize_test.py'' in ''unittest/test''. This way there is a very clear separation between function and test. The problem is making sure the test code loads the function code. Do it wrong a couple of times - it is very instructive for how the search path works. Try to run the test from a different folder, like "pytest test/normalize_test.py" to see how vulnerable just using the path is. 
# You hopefully remember the '''MyMath''' class you made in exercise 1 & 2 in [[Beginning classes]]. Make a folder ''classes'' in your ''unittest/src'' folder and put the ''MyMath'' class in a file ''MyMath.py'' in ''unittest/src/classes''. Now make a unit test file ''MyMath_factorial_test.py'' in ''unittest/test'' that - surprise - tests your factorial method. Test it with at least these input: 12, 2, 1, 0, -1, 3.0, 3.4, "3", "3.1.", "ABC". Parametrize at least the tests that should succeed. Bonus for parametrizing the exceptions. 
# ''MyMath'' class also contains the ''supply'' method. Make unit tests for that method in the file ''unittest/test/MyMath_supply_test.py''. Make the "usual" tests, which are the same as you did in the first exercise. 
# Now make unit tests for the ''average'' method in '''MyMath'''. Make the tests in the file ''unittest/test/MyMath_average_test.py''. Notice how that interacts with the ''supply'' unit tests because ''average'' depends on correct working of ''supply''. Sometimes you won't even find the flaw in one method before you test another that depends on it. I am not going to tell you this time what unit tests you should make. You should know by now.

== Exercises for extra practice ==

Beginning unit test

2026-04-14T14:54:42Z

WikiSysop: /* Exercises to be handed in */

__NOTOC__
{| width=500 style="font-size: 10px; float:right; margin-left: 10px; margin-top: -56px;"
|Previous: [[Intermediate classes]]
|Next: [[Intermediate unit test]]
|}
== Required course material for the lesson ==
Powerpoint: [https://teaching.healthtech.dtu.dk/material/22118/22118_09-Testing.ppt Testing] 
Online: [https://docs.pytest.org/ pytest documentation] 
Resource: [[Example code - Unit test]] 
Resource: [[Unit test - start of reverse polish notation class]] 

=== Installation of pytest ===
If you are using an anaconda python installation pytest is included. You can test in your python has pytest.
# On command line both should work or none
python3 -c "import pytest"
which pytest
# It is pretty clear if you fail. Success can be more obscure.
# Here is a fail test, so you can compare
python3 -c "import yptest"
which yptest
To install pytest, you need to be root/administrator.
# An install on a basic system
pip install -U pytest
# or maybe (depending on your system)
sudo pip install -U pytest
# Using ubuntu, which is also WSL in this situation, there is a package
apt install python3-pytest

== Subjects covered ==
Overview of test methods 
Unit test using pytest framework.

== Exercises to be handed in ==
You should make a special folder for the exercises. I will refer to my special folder as ''unittest'' in these exercises. You will also see some ''__pycache__'' folders appear in places. This is Pythons cache for "compiled" programs. It is safe to ignore and also to delete, because it may become outdated. 
In some of these exercise you need to hand in not just a single file, but multiple files in a folder hierarchy. Zip the folder structure for your entire solution folder. Make sure it is clear to see what exercise your code/data is solving. And learn to zip :-)
# Use your '''normalize''' function from exercise 3 in [[Functions, namespace, memory management]]. If you did not do so already, change it to use exceptions instead of '''sys.exit()''', when an error occurs. Now make simple unit tests for the following test cases: a list of positive numbers, a list of negative numbers, a list of integers, a list of mixed floats and integers, a single number in the list, empty list, a list with at least one non-number (string, list, set), a set containing numbers, and a dict where the keys are numbers. Get other ideas if you can. The '''normalize''' function and all test functions must be in one single file (''normalize_test.py'' in ''unittest''), which you can run ''pytest'' on. 
# Now remove the '''normalize''' function from ''normalize_test.py'' and put it in its own file ''normalize.py''. Import it from the ''normalize_test.py'' like '''from normalize import normalize'''. The first ''normalize'' is the name of the .py file, the second ''normalize'' is the name of your normalize function. Just run ''pytest'' (no file name) in the folder to check it works. It is more normal to have test and function separated. 
# Above we removed test code from function code by creating two files. Next, put the files in their own folder in ''unittest''. I would put my ''normalize.py'' in ''unittest/src'' and ''normalize_test.py'' in ''unittest/test''. This way there is a very clear separation between function and test. The problem is making sure the test code loads the function code. Do it wrong a couple of times - it is very instructive. 
# You hopefully remember the '''MyMath''' class you made in exercise 1 & 2 in [[Beginning classes]]. Make a folder ''classes'' in your ''unittest/src'' folder and put the ''MyMath'' class in a file ''MyMath.py'' in ''unittest/src/classes''. Now make a unit test file ''MyMath_factorial_test.py'' in ''unittest/test'' that - surprise - tests your factorial method. Test it with at least these input: 12, 2, 1, 0, -1, 3.0, 3.4, "3", "3.1.", "ABC". Parametrize at least the tests that should succeed. Bonus for parametrizing the exceptions. 
# ''MyMath'' class also contains the ''supply'' method. Make unit tests for that method in the file ''unittest/test/MyMath_supply_test.py''. Make the "usual" tests, which are the same as you did in the first exercise. 
# Now make unit tests for the ''average'' method in '''MyMath'''. Make the tests in the file ''unittest/test/MyMath_average_test.py''. Notice how that interacts with the ''supply'' unit tests because ''average'' depends on correct working of ''supply''. Sometimes you won't even find the flaw in one method before you test another that depends on it. I am not going to tell you this time what unit tests you should make. You should know by now.

== Exercises for extra practice ==

Beginning unit test

2026-04-14T14:52:37Z

WikiSysop: /* Exercises to be handed in */

__NOTOC__
{| width=500 style="font-size: 10px; float:right; margin-left: 10px; margin-top: -56px;"
|Previous: [[Intermediate classes]]
|Next: [[Intermediate unit test]]
|}
== Required course material for the lesson ==
Powerpoint: [https://teaching.healthtech.dtu.dk/material/22118/22118_09-Testing.ppt Testing] 
Online: [https://docs.pytest.org/ pytest documentation] 
Resource: [[Example code - Unit test]] 
Resource: [[Unit test - start of reverse polish notation class]] 

=== Installation of pytest ===
If you are using an anaconda python installation pytest is included. You can test in your python has pytest.
# On command line both should work or none
python3 -c "import pytest"
which pytest
# It is pretty clear if you fail. Success can be more obscure.
# Here is a fail test, so you can compare
python3 -c "import yptest"
which yptest
To install pytest, you need to be root/administrator.
# An install on a basic system
pip install -U pytest
# or maybe (depending on your system)
sudo pip install -U pytest
# Using ubuntu, which is also WSL in this situation, there is a package
apt install python3-pytest

== Subjects covered ==
Overview of test methods 
Unit test using pytest framework.

== Exercises to be handed in ==
You should make a special folder for the exercises. I will refer to my special folder as ''unittest'' in these exercises. You will also see some ''__pycache__'' folders appear in places. This is Pythons cache for "compiled" programs. It is safe to ignore and also to delete, because it may become outdated. 
In some of these exercise you need to hand in not just a single file, but multiple files in a folder hierarchy. Zip the folder structure for your entire solution folder. Make sure it is clear to see what exercise your code/data is solving. And learn to zip :-)
# Use your '''normalize''' function from exercise 3 in [[Functions, namespace, memory management]]. If you did not do so already, change it to use exceptions instead of '''sys.exit()''', when an error occurs. Now make simple unit tests for the following test cases: a list of positive numbers, a list of negative numbers, a list of integers, a list of mixed floats and integers, a single number in the list, empty list, a list with at least one non-number (string, list, set), a set containing numbers, and a dict where the keys are numbers. Get other ideas if you can. The '''normalize''' function and all test functions must be in one single file (''normalize_test.py'' in ''unittest''), which you can run ''pytest'' on. 
# Now remove the '''normalize''' function from ''normalize_test.py'' and put it in its own file ''normalize.py''. Import it from the ''normalize_test.py'' like '''from normalize import normalize'''. The first ''normalize'' is the name of the .py file, the second ''normalize'' is the name of your normalize function. Just run ''pytest'' (no file name) in the folder to check it works. It is more normal to have test and function separated. 
# Above we removed test code from function code by creating two files. Next, put the files in their own folder in ''unittest''. I would put my ''normalize.py'' in ''unittest/src'' and ''normalize_test.py'' in ''unittest/test''. This way there is a very clear separation between function and test. The problem is making sure the test code loads the function code. Do it wrong a couple of times - it is very instructive. 
# You hopefully remember the '''MyMath''' class you made in exercise 1 & 2 in [[Beginning classes]]. Make a folder ''classes'' in your ''unittest/src'' folder and put the ''MyMath'' class in a file ''MyMath.py'' in ''unittest/src/classes''. Now make a unit test file ''MyMath_factorial_test.py'' in ''unittest/test'' that - surprise - tests your factorial method. Test it with at least these input: 12, 2, 1, 0, -1, 3.0, 3.4, "3", "3.1.", "ABC". Parametrize at least the tests that should succeed. Bonus for parametrizing the exceptions. 
# ''MyMath'' class also contains the ''supply'' method. Make unit tests for that method in the file ''unittest/test/MyMath_supply_test.py''. Make the "usual" tests, which are the same as you did in the first exercise. 
# Now make unit tests for the ''average'' method in '''MyMath'''. Use the file ''unittest/test/MyMath_average_test.py''. Notice how that interacts with the ''supply'' unit tests because ''average'' depends on correct working of ''supply''. Sometimes you won't even find the flaw in one method before you test another that depends on it.

== Exercises for extra practice ==

Beginning unit test

2026-04-14T14:50:46Z

WikiSysop: /* Exercises to be handed in */

__NOTOC__
{| width=500 style="font-size: 10px; float:right; margin-left: 10px; margin-top: -56px;"
|Previous: [[Intermediate classes]]
|Next: [[Intermediate unit test]]
|}
== Required course material for the lesson ==
Powerpoint: [https://teaching.healthtech.dtu.dk/material/22118/22118_09-Testing.ppt Testing] 
Online: [https://docs.pytest.org/ pytest documentation] 
Resource: [[Example code - Unit test]] 
Resource: [[Unit test - start of reverse polish notation class]] 

=== Installation of pytest ===
If you are using an anaconda python installation pytest is included. You can test in your python has pytest.
# On command line both should work or none
python3 -c "import pytest"
which pytest
# It is pretty clear if you fail. Success can be more obscure.
# Here is a fail test, so you can compare
python3 -c "import yptest"
which yptest
To install pytest, you need to be root/administrator.
# An install on a basic system
pip install -U pytest
# or maybe (depending on your system)
sudo pip install -U pytest
# Using ubuntu, which is also WSL in this situation, there is a package
apt install python3-pytest

== Subjects covered ==
Overview of test methods 
Unit test using pytest framework.

== Exercises to be handed in ==
You should make a special folder for the exercises. I will refer to my special folder as ''unittest'' in these exercises. You will also see some ''__pycache__'' folders appear in places. This is Pythons cache for "compiled" programs. It is safe to ignore and also to delete, because it may become outdated. 
In some of these exercise you need to hand in not just a single file, but multiple files in a folder hierarchy. Zip the folder structure for your entire solution folder. Make sure it is clear to see what exercise your code/data is solving. And learn to zip :-)
# Use your '''normalize''' function from exercise 3 in [[Functions, namespace, memory management]]. If you did not do so already, change it to use exceptions instead of '''sys.exit()''', when an error occurs. Now make simple unit tests for the following test cases: a list of positive numbers, a list of negative numbers, a list of integers, a list of mixed floats and integers, a single number in the list, empty list, a list with at least one non-number (string, list, set), a set containing numbers, and a dict where the keys are numbers. Get other ideas if you can. The '''normalize''' function and all test functions must be in one single file (''normalize_test.py'' in ''unittest''), which you can run ''pytest'' on. 
# Now remove the '''normalize''' function from ''normalize_test.py'' and put it in its own file ''normalize.py''. Import it from the ''normalize_test.py'' like '''from normalize import normalize'''. The first ''normalize'' is the name of the .py file, the second ''normalize'' is the name of your normalize function. Just run ''pytest'' (no file name) in the folder to check it works. It is more normal to have test and function separated. 
# Above we removed test code from function code by creating two files. Next, put the files in their own folder in ''unittest''. I would put my ''normalize.py'' in ''unittest/src'' and ''normalize_test.py'' in ''unittest/test''. This way there is a very clear separation between function and test. The problem is making sure the test code loads the function code. Do it wrong a couple of times - it is very instructive. 
# You hopefully remember the '''MyMath''' class you made in exercise 1 & 2 in [[Beginning classes]]. Make a folder ''classes'' in your ''unittest/src'' folder and put the ''MyMath'' class in a file ''MyMath.py'' in ''unittest/src/classes''. Now make a unit test file ''MyMath_factorial_test.py'' in ''unittest/test'' that - surprise - tests your factorial method. Test it with at least these input: 12, 2, 1, 0, -1, 3.0, 3.4, "3", "3.1.", "ABC". Parametrize at least the tests that should succeed. Bonus for parametrizing the exceptions. 
# ''MyMath'' class also contains the ''supply'' method. Make unit tests for that method in the file ''unittest/test/MyMath_supply_test.py''. Make the "usual" tests, which are the same as you did in the first exercise. 
# Now make unit tests for the ''average'' method in ''MyMath''. Use the file ''unittest/test/MyMath_average_test.py''. Notice how that interacts with the ''supply'' unit tests because ''average'' depends on correct working of ''supply''. Sometimes you won't even find the flaw in one method before you test another dependency.

== Exercises for extra practice ==

Beginning unit test

2026-04-14T14:50:20Z

WikiSysop: /* Exercises to be handed in */

__NOTOC__
{| width=500 style="font-size: 10px; float:right; margin-left: 10px; margin-top: -56px;"
|Previous: [[Intermediate classes]]
|Next: [[Intermediate unit test]]
|}
== Required course material for the lesson ==
Powerpoint: [https://teaching.healthtech.dtu.dk/material/22118/22118_09-Testing.ppt Testing] 
Online: [https://docs.pytest.org/ pytest documentation] 
Resource: [[Example code - Unit test]] 
Resource: [[Unit test - start of reverse polish notation class]] 

=== Installation of pytest ===
If you are using an anaconda python installation pytest is included. You can test in your python has pytest.
# On command line both should work or none
python3 -c "import pytest"
which pytest
# It is pretty clear if you fail. Success can be more obscure.
# Here is a fail test, so you can compare
python3 -c "import yptest"
which yptest
To install pytest, you need to be root/administrator.
# An install on a basic system
pip install -U pytest
# or maybe (depending on your system)
sudo pip install -U pytest
# Using ubuntu, which is also WSL in this situation, there is a package
apt install python3-pytest

== Subjects covered ==
Overview of test methods 
Unit test using pytest framework.

== Exercises to be handed in ==
You should make a special folder for the exercises. I will refer to my special folder as ''unittest'' in these exercises. You will also see some ''__pycache__'' folders appear in places. This is Pythons cache for "compiled" programs. It is safe to ignore and also to delete, because it may become outdated. 
In some of these exercise you need to hand in not just a single file, but multiple files in a folder hierarchy. Zip the folder structure for your entire solution folder. Make sure it is clear to see what exercise your code/data is solving. And learn to zip :-)
# Use your '''normalize''' function from exercise 3 in [[Functions, namespace, memory management]]. If you did not do so already, change it to use exceptions instead of '''sys.exit()''', when an error occurs. Now make simple unit tests for the following test cases: a list of positive numbers, a list of negative numbers, a list of integers, a list of mixed floats and integers, a single number in the list, empty list, a list with at least one non-number (string, list, set), a set containing numbers, and a dict where the keys are numbers. Get other ideas if you can. The '''normalize''' function and all test functions must be in one single file (''normalize_test.py'' in ''unittest''), which you can run ''pytest'' on. 
# Now remove the '''normalize''' function from ''normalize_test.py'' and put it in its own file ''normalize.py''. Import it from the ''normalize_test.py'' like '''from normalize import normalize'''. The first ''normalize'' is the name of the .py file, the second ''normalize'' is the name of your normalize function. Just run ''pytest'' (no file name) in the folder to check it works. It is more normal to have test and function separated. 
# Above we removed test code from function code by creating two files. Next, put the files in their own folder in ''unittest''. I would put my ''normalize.py'' in ''unittest/src'' and ''normalize_test.py'' in ''unittest/test''. This way there is a very clear separation between function and test. The problem is making sure the test code loads the function code. Do it wrong a couple of times - it is very instructive. 
# You hopefully remember the '''MyMath''' class you made in exercise 1 & 2 in [[Beginning classes]]. Make a folder ''classes'' in your ''unittest/src'' folder and put the ''MyMath'' class in a file ''MyMath.py'' in ''unittest/src/classes''. Now make a unit test file ''MyMath_factorial_test.py'' in ''unittest/test'' that - surprise - tests your factorial method. Test it with at least these input: 12, 2, 1, 0, -1, 3.0, 3.4, "3", "3.1.", "ABC". Parametrize at least the tests that should succeed. Bonus for parametrizing the exceptions.
# ''MyMath'' class also contains the ''supply'' method. Make unit tests for that method in the file ''unittest/test/MyMath_supply_test.py''. Make the "usual" tests, which are the same as you did in the first exercise.
# Now make unit tests for the ''average'' method in ''MyMath''. Use the file ''unittest/test/MyMath_average_test.py''. Notice how that interacts with the ''supply'' unit tests because ''average'' depends on correct working of ''supply''. Sometimes you won't even find the flaw in one method before you test another dependency.

== Exercises for extra practice ==

Beginning unit test

2026-04-14T14:39:24Z

WikiSysop: /* Installation of pytest */

__NOTOC__
{| width=500 style="font-size: 10px; float:right; margin-left: 10px; margin-top: -56px;"
|Previous: [[Intermediate classes]]
|Next: [[Intermediate unit test]]
|}
== Required course material for the lesson ==
Powerpoint: [https://teaching.healthtech.dtu.dk/material/22118/22118_09-Testing.ppt Testing] 
Online: [https://docs.pytest.org/ pytest documentation] 
Resource: [[Example code - Unit test]] 
Resource: [[Unit test - start of reverse polish notation class]] 

=== Installation of pytest ===
If you are using an anaconda python installation pytest is included. You can test in your python has pytest.
# On command line both should work or none
python3 -c "import pytest"
which pytest
# It is pretty clear if you fail. Success can be more obscure.
# Here is a fail test, so you can compare
python3 -c "import yptest"
which yptest
To install pytest, you need to be root/administrator.
# An install on a basic system
pip install -U pytest
# or maybe (depending on your system)
sudo pip install -U pytest
# Using ubuntu, which is also WSL in this situation, there is a package
apt install python3-pytest

== Subjects covered ==
Overview of test methods 
Unit test using pytest framework.

== Exercises to be handed in ==
You should make a special folder for the exercises. I will refer to my special folder as ''unittest'' in these exercises. You will also see some ''__pycache__'' folders appear in places. This is Pythons cache for "compiled" programs. It is safe to ignore and also to delete, because it may become outdated. 
In some of these exercise you need to hand in not just a single file, but multiple files in a folder hierarchy. Zip the folder structure for your entire solution folder. Make sure it is clear to see what exercise your code/data is solving. And learn to zip :-)
# Use your '''normalize''' function from exercise 3 in [[Functions, namespace, memory management]]. If you did not do so already, change it to use exceptions instead of '''sys.exit()''', when an error occurs. Now make simple unit tests for the following test cases: a list of positive numbers, a list of negative numbers, a list of integers, a list of mixed floats and integers, a single number in the list, empty list, a list with at least one non-number (string, list, set), a set containing numbers, and a dict where the keys are numbers. Get other ideas if you can. The '''normalize''' function and all test functions must be in one single file (''normalize_test.py'' in ''unittest''), which you can run ''pytest'' on. 
# Now remove the '''normalize''' function from ''normalize_test.py'' and put it in its own file ''normalize.py''. Import it from the ''normalize_test.py'' like '''from normalize import normalize'''. The first ''normalize'' is the name of the .py file, the second ''normalize'' is the name of your normalize function. Just run ''pytest'' (no file name) in the folder to check it works. It is more normal to have test and function separated. 
# Above we removed test code from function code by creating two files. Next, put the files in their own folder in ''unittest''. I would put my ''normalize.py'' in ''unittest/src'' and ''normalize_test.py'' in ''unittest/test''. This way there is a very clear separation between function and test. The problem is making sure the test code loads the function code. Do it wrong a couple of times - it is very instructive. 
# You hopefully remember the '''MyMath''' class you made in exercise 1 & 2 in [[Beginning classes]]. Make a folder ''classes'' in your ''unittest/src'' folder and put the ''MyMath'' class in a file ''MyMath.py'' in ''unittest/src/classes''. Now make a unit test file ''MyMath_factorial_test.py'' in ''unittest/test'' that - surprise - tests your factorial method. Test it with at least these input: 12, 2, 1, 0, -1, 3.0, 3.4, "3", "3.1.", "ABC". Parametrize at least the tests that should succeed. Bonus for parametrizing the exceptions.

== Exercises for extra practice ==

Intermediate unit test

2026-04-14T14:35:42Z

WikiSysop: /* Exercises for extra practice */

__NOTOC__
{| width=500 style="font-size: 10px; float:right; margin-left: 10px; margin-top: -56px;"
|Previous: [[Beginning unit test]]
|Next: [[Runtime evaluation]]
|}
== Required course material for the lesson ==
Powerpoint: [https://teaching.healthtech.dtu.dk/material/22118/22118_09-Testing.ppt Testing] 
Online: [https://docs.pytest.org/ pytest documentation] 
Resource: [[Unit test - start of reverse polish notation class]] 
Blog: [https://www.joelonsoftware.com/2000/04/30/top-five-wrong-reasons-you-dont-have-testers/ On testing], by the founder of StackExchange. 

== Subjects covered ==
Unit test using pytest framework. 
Files, test data 
Setting up real projects 

== Exercises to be handed in ==
You should make a special folder for the exercises. I will refer to my special folder as ''unittest'' in these exercises. You will also see some ''__pycache__'' folders appear in places. This is Pythons cache for "compiled" programs. It is safe to ignore and also to delete, because it may become outdated.
# Follow the file structure of having a ''code'' (or ''src'') folder for programs, a ''test'' folder for tests, and now a ''testdata'' folder for files containing test data. Now make unit tests and appropriate test data files for your '''fasta''' class from last week. In this exercise you just need to make unit test for the method '''load'''. You need to hand in both tests and test data. 
# Add unit tests for the method '''save''' in your '''fasta''' class. Hand in same way as above. 
# Add unit tests for the method '''delete''' in your '''fasta''' class. Hand in same way as above. 
I would not be surprised if you find errors in your '''fasta''' class based on these tests. I found flaws in my code.

== Exercises for extra practice ==
# Add unit tests for all methods in your '''fasta''' class. That will be a bit of work.

Beginning unit test

2026-04-14T14:35:31Z

WikiSysop: /* Exercises for extra practice */

__NOTOC__
{| width=500 style="font-size: 10px; float:right; margin-left: 10px; margin-top: -56px;"
|Previous: [[Intermediate classes]]
|Next: [[Intermediate unit test]]
|}
== Required course material for the lesson ==
Powerpoint: [https://teaching.healthtech.dtu.dk/material/22118/22118_09-Testing.ppt Testing] 
Online: [https://docs.pytest.org/ pytest documentation] 
Resource: [[Example code - Unit test]] 
Resource: [[Unit test - start of reverse polish notation class]] 

=== Installation of pytest ===
If you are using an anaconda python installation pytest is included. You can test in your python has pytest.
# On command line both should work or none
python3 -c "import pytest"
which pytest
# It is pretty clear if you fail. Success can be more obscure.
# Here is a fail test, so you can compare
python3 -c "import yptest"
which yptest
To install pytest, you need to be root/administrator.
pip install -U pytest
# or maybe (depending on your system)
sudo pip install -U pytest

== Subjects covered ==
Overview of test methods 
Unit test using pytest framework.

== Exercises to be handed in ==
You should make a special folder for the exercises. I will refer to my special folder as ''unittest'' in these exercises. You will also see some ''__pycache__'' folders appear in places. This is Pythons cache for "compiled" programs. It is safe to ignore and also to delete, because it may become outdated. 
In some of these exercise you need to hand in not just a single file, but multiple files in a folder hierarchy. Zip the folder structure for your entire solution folder. Make sure it is clear to see what exercise your code/data is solving. And learn to zip :-)
# Use your '''normalize''' function from exercise 3 in [[Functions, namespace, memory management]]. If you did not do so already, change it to use exceptions instead of '''sys.exit()''', when an error occurs. Now make simple unit tests for the following test cases: a list of positive numbers, a list of negative numbers, a list of integers, a list of mixed floats and integers, a single number in the list, empty list, a list with at least one non-number (string, list, set), a set containing numbers, and a dict where the keys are numbers. Get other ideas if you can. The '''normalize''' function and all test functions must be in one single file (''normalize_test.py'' in ''unittest''), which you can run ''pytest'' on. 
# Now remove the '''normalize''' function from ''normalize_test.py'' and put it in its own file ''normalize.py''. Import it from the ''normalize_test.py'' like '''from normalize import normalize'''. The first ''normalize'' is the name of the .py file, the second ''normalize'' is the name of your normalize function. Just run ''pytest'' (no file name) in the folder to check it works. It is more normal to have test and function separated. 
# Above we removed test code from function code by creating two files. Next, put the files in their own folder in ''unittest''. I would put my ''normalize.py'' in ''unittest/src'' and ''normalize_test.py'' in ''unittest/test''. This way there is a very clear separation between function and test. The problem is making sure the test code loads the function code. Do it wrong a couple of times - it is very instructive. 
# You hopefully remember the '''MyMath''' class you made in exercise 1 & 2 in [[Beginning classes]]. Make a folder ''classes'' in your ''unittest/src'' folder and put the ''MyMath'' class in a file ''MyMath.py'' in ''unittest/src/classes''. Now make a unit test file ''MyMath_factorial_test.py'' in ''unittest/test'' that - surprise - tests your factorial method. Test it with at least these input: 12, 2, 1, 0, -1, 3.0, 3.4, "3", "3.1.", "ABC". Parametrize at least the tests that should succeed. Bonus for parametrizing the exceptions.

== Exercises for extra practice ==

Beginning unit test

2026-04-14T14:32:23Z

WikiSysop: /* Exercises to be handed in */

__NOTOC__
{| width=500 style="font-size: 10px; float:right; margin-left: 10px; margin-top: -56px;"
|Previous: [[Intermediate classes]]
|Next: [[Intermediate unit test]]
|}
== Required course material for the lesson ==
Powerpoint: [https://teaching.healthtech.dtu.dk/material/22118/22118_09-Testing.ppt Testing] 
Online: [https://docs.pytest.org/ pytest documentation] 
Resource: [[Example code - Unit test]] 
Resource: [[Unit test - start of reverse polish notation class]] 

=== Installation of pytest ===
If you are using an anaconda python installation pytest is included. You can test in your python has pytest.
# On command line both should work or none
python3 -c "import pytest"
which pytest
# It is pretty clear if you fail. Success can be more obscure.
# Here is a fail test, so you can compare
python3 -c "import yptest"
which yptest
To install pytest, you need to be root/administrator.
pip install -U pytest
# or maybe (depending on your system)
sudo pip install -U pytest

== Subjects covered ==
Overview of test methods 
Unit test using pytest framework.

== Exercises to be handed in ==
You should make a special folder for the exercises. I will refer to my special folder as ''unittest'' in these exercises. You will also see some ''__pycache__'' folders appear in places. This is Pythons cache for "compiled" programs. It is safe to ignore and also to delete, because it may become outdated. 
In some of these exercise you need to hand in not just a single file, but multiple files in a folder hierarchy. Zip the folder structure for your entire solution folder. Make sure it is clear to see what exercise your code/data is solving. And learn to zip :-)
# Use your '''normalize''' function from exercise 3 in [[Functions, namespace, memory management]]. If you did not do so already, change it to use exceptions instead of '''sys.exit()''', when an error occurs. Now make simple unit tests for the following test cases: a list of positive numbers, a list of negative numbers, a list of integers, a list of mixed floats and integers, a single number in the list, empty list, a list with at least one non-number (string, list, set), a set containing numbers, and a dict where the keys are numbers. Get other ideas if you can. The '''normalize''' function and all test functions must be in one single file (''normalize_test.py'' in ''unittest''), which you can run ''pytest'' on. 
# Now remove the '''normalize''' function from ''normalize_test.py'' and put it in its own file ''normalize.py''. Import it from the ''normalize_test.py'' like '''from normalize import normalize'''. The first ''normalize'' is the name of the .py file, the second ''normalize'' is the name of your normalize function. Just run ''pytest'' (no file name) in the folder to check it works. It is more normal to have test and function separated. 
# Above we removed test code from function code by creating two files. Next, put the files in their own folder in ''unittest''. I would put my ''normalize.py'' in ''unittest/src'' and ''normalize_test.py'' in ''unittest/test''. This way there is a very clear separation between function and test. The problem is making sure the test code loads the function code. Do it wrong a couple of times - it is very instructive. 
# You hopefully remember the '''MyMath''' class you made in exercise 1 & 2 in [[Beginning classes]]. Make a folder ''classes'' in your ''unittest/src'' folder and put the ''MyMath'' class in a file ''MyMath.py'' in ''unittest/src/classes''. Now make a unit test file ''MyMath_factorial_test.py'' in ''unittest/test'' that - surprise - tests your factorial method. Test it with at least these input: 12, 2, 1, 0, -1, 3.0, 3.4, "3", "3.1.", "ABC". Parametrize at least the tests that should succeed. Bonus for parametrizing the exceptions.

== Exercises for extra practice ==
# Add unit tests for all methods in your '''fasta''' class. That will be a bit of work.

Beginning unit test

2026-04-14T14:32:02Z

WikiSysop: /* Exercises to be handed in */

__NOTOC__
{| width=500 style="font-size: 10px; float:right; margin-left: 10px; margin-top: -56px;"
|Previous: [[Intermediate classes]]
|Next: [[Intermediate unit test]]
|}
== Required course material for the lesson ==
Powerpoint: [https://teaching.healthtech.dtu.dk/material/22118/22118_09-Testing.ppt Testing] 
Online: [https://docs.pytest.org/ pytest documentation] 
Resource: [[Example code - Unit test]] 
Resource: [[Unit test - start of reverse polish notation class]] 

=== Installation of pytest ===
If you are using an anaconda python installation pytest is included. You can test in your python has pytest.
# On command line both should work or none
python3 -c "import pytest"
which pytest
# It is pretty clear if you fail. Success can be more obscure.
# Here is a fail test, so you can compare
python3 -c "import yptest"
which yptest
To install pytest, you need to be root/administrator.
pip install -U pytest
# or maybe (depending on your system)
sudo pip install -U pytest

== Subjects covered ==
Overview of test methods 
Unit test using pytest framework.

== Exercises to be handed in ==
You should make a special folder for the exercises. I will refer to my special folder as ''unittest'' in these exercises. You will also see some ''__pycache__'' folders appear in places. This is Pythons cache for "compiled" programs. It is safe to ignore and also to delete, because it may become outdated. 
In some of these exercise you need to hand in not just a single file, but multiple files in a folder hierarchy. Zip the folder structure for your entire solution folder. Make sure it is clear to see what exercise your code/data is solving. And learn to zip :-)
# Use your '''normalize''' function from exercise 3 in [[Functions, namespace, memory management]]. If you did not do so already, change it to use exceptions instead of '''sys.exit()''', when an error occurs. Now make simple unit tests for the following test cases: a list of positive numbers, a list of negative numbers, a list of integers, a list of mixed floats and integers, a single number in the list, empty list, a list with at least one non-number (string, list, set), a set containing numbers, and a dict where the keys are numbers. Get other ideas if you can. The '''normalize''' function and all test functions must be in one single file (''normalize_test.py'' in ''unittest''), which you can run ''pytest'' on. 
# Now remove the '''normalize''' function from ''normalize_test.py'' and put it in its own file ''normalize.py''. Import it from the ''normalize_test.py'' like '''from normalize import normalize'''. The first ''normalize'' is the name of the .py file, the second ''normalize'' is the name of your normalize function. Just run ''pytest'' (no file name) in the folder to check it works. It is more normal to have test and function separated. 
# Above we removed test code from function code by creating two files. Next, put the files in their own folder in ''unittest''. I would put my ''normalize.py'' in ''unittest/src'' and ''normalize_test.py'' in ''unittest/test''. This way there is a very clear separation between function and test. The problem is making sure the test code loads the function code. Do it wrong a couple of times - it is very instructive. 
# You hopefully remember the '''MyMath''' class you made in exercise 1 & 2 in [[Beginning classes]]. Make a folder ''classes'' in your ''unittest/src'' folder and put the ''MyMath'' class in a file ''MyMath.py'' in 'unittest/src/classes''. Now make a unit test file ''MyMath_factorial_test.py'' in ''unittest/test'' that - surprise - tests your factorial method. Test it with at least these input: 12, 2, 1, 0, -1, 3.0, 3.4, "3", "3.1.", "ABC". Parametrize at least the tests that should succeed. Bonus for parametrizing the exceptions.

== Exercises for extra practice ==
# Add unit tests for all methods in your '''fasta''' class. That will be a bit of work.

Beginning unit test

2026-04-14T14:26:39Z

WikiSysop: /* Exercises to be handed in */

__NOTOC__
{| width=500 style="font-size: 10px; float:right; margin-left: 10px; margin-top: -56px;"
|Previous: [[Intermediate classes]]
|Next: [[Intermediate unit test]]
|}
== Required course material for the lesson ==
Powerpoint: [https://teaching.healthtech.dtu.dk/material/22118/22118_09-Testing.ppt Testing] 
Online: [https://docs.pytest.org/ pytest documentation] 
Resource: [[Example code - Unit test]] 
Resource: [[Unit test - start of reverse polish notation class]] 

=== Installation of pytest ===
If you are using an anaconda python installation pytest is included. You can test in your python has pytest.
# On command line both should work or none
python3 -c "import pytest"
which pytest
# It is pretty clear if you fail. Success can be more obscure.
# Here is a fail test, so you can compare
python3 -c "import yptest"
which yptest
To install pytest, you need to be root/administrator.
pip install -U pytest
# or maybe (depending on your system)
sudo pip install -U pytest

== Subjects covered ==
Overview of test methods 
Unit test using pytest framework.

== Exercises to be handed in ==
You should make a special folder for the exercises. I will refer to my special folder as ''unittest'' in these exercises. You will also see some ''__pycache__'' folders appear in places. This is Pythons cache for "compiled" programs. It is safe to ignore and also to delete, because it may become outdated. 
In some of these exercise you need to hand in not just a single file, but multiple files in a folder hierarchy. Zip the folder structure for your entire solution folder. Make sure it is clear to see what exercise your code/data is solving. And learn to zip :-)
# Use your '''normalize''' function from exercise 3 in [[Functions, namespace, memory management]]. If you did not do so already, change it to use exceptions instead of '''sys.exit()''', when an error occurs. Now make simple unit tests for the following test cases: a list of positive numbers, a list of negative numbers, a list of integers, a list of mixed floats and integers, a single number in the list, empty list, a list with at least one non-number (string, list, set), a set containing numbers, and a dict where the keys are numbers. Get other ideas if you can. The '''normalize''' function and all test functions must be in one single file (''normalize_test.py'' in ''unittest''), which you can run ''pytest'' on. 
# Now remove the '''normalize''' function from ''normalize_test.py'' and put it in its own file ''normalize.py''. Import it from the ''normalize_test.py'' like '''from normalize import normalize'''. The first ''normalize'' is the name of the .py file, the second ''normalize'' is the name of your normalize function. Just run ''pytest'' (no file name) in the folder to check it works. It is more normal to have test and function separated. 
# Above we removed test code from function code by creating two files. Next, put the files in their own folder in ''unittest''. I would put my ''normalize.py'' in ''unittest/src'' and ''normalize_test.py'' in ''unittest/test''. This way there is a very clear separation between function and test. The problem is making sure the test code loads the function code. Do it wrong a couple of times - it is very instructive. 
# You hopefully remember the '''MyMath''' class you made in exercise 1 & 2 in [[Beginning classes]]. Make a folder ''classes' in your ''unittest/src'' folder and put the ''MyMath'' class in a file ''MyMath.py'' in 'unittest/src/classes''. Now make a unit test file ''MyMath_factorial_test.py'' in ''unittest/test'' that - surprise - tests your factorial method.

== Exercises for extra practice ==
# Add unit tests for all methods in your '''fasta''' class. That will be a bit of work.

Intermediate unit test

2026-04-14T14:16:24Z

WikiSysop: /* Exercises to be handed in */

__NOTOC__
{| width=500 style="font-size: 10px; float:right; margin-left: 10px; margin-top: -56px;"
|Previous: [[Beginning unit test]]
|Next: [[Runtime evaluation]]
|}
== Required course material for the lesson ==
Powerpoint: [https://teaching.healthtech.dtu.dk/material/22118/22118_09-Testing.ppt Testing] 
Online: [https://docs.pytest.org/ pytest documentation] 
Resource: [[Unit test - start of reverse polish notation class]] 
Blog: [https://www.joelonsoftware.com/2000/04/30/top-five-wrong-reasons-you-dont-have-testers/ On testing], by the founder of StackExchange. 

== Subjects covered ==
Unit test using pytest framework. 
Files, test data 
Setting up real projects 

== Exercises to be handed in ==
You should make a special folder for the exercises. I will refer to my special folder as ''unittest'' in these exercises. You will also see some ''__pycache__'' folders appear in places. This is Pythons cache for "compiled" programs. It is safe to ignore and also to delete, because it may become outdated.
# Follow the file structure of having a ''code'' (or ''src'') folder for programs, a ''test'' folder for tests, and now a ''testdata'' folder for files containing test data. Now make unit tests and appropriate test data files for your '''fasta''' class from last week. In this exercise you just need to make unit test for the method '''load'''. You need to hand in both tests and test data. 
# Add unit tests for the method '''save''' in your '''fasta''' class. Hand in same way as above. 
# Add unit tests for the method '''delete''' in your '''fasta''' class. Hand in same way as above. 
I would not be surprised if you find errors in your '''fasta''' class based on these tests. I found flaws in my code.

== Exercises for extra practice ==

Beginning unit test

2026-04-14T14:15:55Z

WikiSysop: /* Exercises to be handed in */

__NOTOC__
{| width=500 style="font-size: 10px; float:right; margin-left: 10px; margin-top: -56px;"
|Previous: [[Intermediate classes]]
|Next: [[Intermediate unit test]]
|}
== Required course material for the lesson ==
Powerpoint: [https://teaching.healthtech.dtu.dk/material/22118/22118_09-Testing.ppt Testing] 
Online: [https://docs.pytest.org/ pytest documentation] 
Resource: [[Example code - Unit test]] 
Resource: [[Unit test - start of reverse polish notation class]] 

=== Installation of pytest ===
If you are using an anaconda python installation pytest is included. You can test in your python has pytest.
# On command line both should work or none
python3 -c "import pytest"
which pytest
# It is pretty clear if you fail. Success can be more obscure.
# Here is a fail test, so you can compare
python3 -c "import yptest"
which yptest
To install pytest, you need to be root/administrator.
pip install -U pytest
# or maybe (depending on your system)
sudo pip install -U pytest

== Subjects covered ==
Overview of test methods 
Unit test using pytest framework.

== Exercises to be handed in ==
You should make a special folder for the exercises. I will refer to my special folder as ''unittest'' in these exercises. You will also see some ''__pycache__'' folders appear in places. This is Pythons cache for "compiled" programs. It is safe to ignore and also to delete, because it may become outdated. 
In some of these exercise you need to hand in not just a single file, but multiple files in a folder hierarchy. Zip the folder structure for your entire solution folder. Make sure it is clear to see what exercise your code/data is solving. And learn to zip :-)
# Use your '''normalize''' function from exercise 3 in [[Functions, namespace, memory management]]. If you did not do so already, change it to use exceptions instead of '''sys.exit()''', when an error occurs. Now make simple unit tests for the following test cases: a list of positive numbers, a list of negative numbers, a list of integers, a list of mixed floats and integers, a single number in the list, empty list, a list with at least one non-number (string, list, set), a set containing numbers, and a dict where the keys are numbers. Get other ideas if you can. The '''normalize''' function and all test functions must be in one single file (''normalize_test.py'' in ''unittest''), which you can run ''pytest'' on. 
# Now remove the '''normalize''' function from ''normalize_test.py'' and put it in its own file ''normalize.py''. Import it from the ''normalize_test.py'' like '''from normalize import normalize'''. The first ''normalize'' is the name of the .py file, the second ''normalize'' is the name of your normalize function. Just run ''pytest'' (no file name) in the folder to check it works. It is more normal to have test and function separated. 
# Above we removed test code from function code by creating two files. Next, put the files in their own folder in ''unittest''. I would put my ''normalize.py'' in ''unittest/src'' and ''normalize_test.py'' in ''unittest/test''. This way there is a very clear separation between function and test. The problem is making sure the test code loads the function code. Do it wrong a couple of times - it is very instructive. 

== Exercises for extra practice ==
# Add unit tests for all methods in your '''fasta''' class. That will be a bit of work.

Beginning unit test

2026-04-13T10:06:00Z

WikiSysop: /* Required course material for the lesson */

__NOTOC__
{| width=500 style="font-size: 10px; float:right; margin-left: 10px; margin-top: -56px;"
|Previous: [[Intermediate classes]]
|Next: [[Intermediate unit test]]
|}
== Required course material for the lesson ==
Powerpoint: [https://teaching.healthtech.dtu.dk/material/22118/22118_09-Testing.ppt Testing] 
Online: [https://docs.pytest.org/ pytest documentation] 
Resource: [[Example code - Unit test]] 
Resource: [[Unit test - start of reverse polish notation class]] 

=== Installation of pytest ===
If you are using an anaconda python installation pytest is included. You can test in your python has pytest.
# On command line both should work or none
python3 -c "import pytest"
which pytest
# It is pretty clear if you fail. Success can be more obscure.
# Here is a fail test, so you can compare
python3 -c "import yptest"
which yptest
To install pytest, you need to be root/administrator.
pip install -U pytest
# or maybe (depending on your system)
sudo pip install -U pytest

== Subjects covered ==
Overview of test methods 
Unit test using pytest framework.

== Exercises to be handed in ==
You should make a special folder for the exercises. I will refer to my special folder as ''unittest'' in these exercises. You will also see some ''__pycache__'' folders appear in places. This is Pythons cache for "compiled" programs. It is safe to ignore and also to delete, because it may become outdated. 
In some of these exercise you need to hand in not just a single file, but multiple files in a folder hierarchy. Zip the folder structure for your entire solution folder. Make sure it is clear to see what exercise your code/data is solving. And learn to zip :-)
# Use your '''normalize''' function from exercise 3 in [[Functions, namespace, memory management]]. If you did not do so already, change it to use exceptions instead of '''sys.exit()''', when an error occurs. Now make simple unit tests for the following test cases: a list of positive numbers, a list of negative numbers, a list of integers, a list of mixed floats and integers, a single number in the list, empty list, a list with at least one non-number (string, list, set), a set containing numbers, and a dict where the keys are numbers. Get other ideas if you can. The '''normalize''' function and all test functions must be in one single file (''normalize_test.py'' in ''unittest''), which you can run ''pytest'' on. 
# Now remove the '''normalize''' function from ''normalize_test.py'' and put it in its own file ''normalize.py''. Import it from the ''normalize_test.py'' like '''from normalize import normalize'''. The first ''normalize'' is the name of the .py file, the second ''normalize'' is the name of your normalize function. Just run ''pytest'' (no file name) in the folder to check it works. It is more normal to have test and function separated. 
# Above we removed test code from function code by creating two files. Next, put the files in their own folder in ''unittest''. I would put my ''normalize.py'' in ''unittest/src'' and ''normalize_test.py'' in ''unittest/test''. This way there is a very clear separation between function and test. The problem is making sure the test code loads the function code. Do it wrong a couple of times - it is very instructive. 
# Follow the file structure of having a ''code'' (or ''src'') folder for programs, a ''test'' folder for tests, and now a ''testdata'' folder for files containing test data. Now make unit tests and appropriate test data files for your '''fasta''' class from last week. In this exercise you just need to make unit test for the method '''load'''. You need to hand in both tests and test data. 
# Add unit tests for the method '''save''' in your '''fasta''' class. Hand in same way as above. 
# Add unit tests for the method '''delete''' in your '''fasta''' class. Hand in same way as above. 
I would not be surprised if you find errors in your '''fasta''' class based on these tests. I found flaws in my code.

== Exercises for extra practice ==
# Add unit tests for all methods in your '''fasta''' class. That will be a bit of work.

Beginning unit test

2026-04-13T09:52:42Z

WikiSysop: /* Exercises to be handed in */

__NOTOC__
{| width=500 style="font-size: 10px; float:right; margin-left: 10px; margin-top: -56px;"
|Previous: [[Intermediate classes]]
|Next: [[Intermediate unit test]]
|}
== Required course material for the lesson ==
Powerpoint: [https://teaching.healthtech.dtu.dk/material/22118/22118_09-Testing.ppt Testing] 
Online: [https://docs.pytest.org/ pytest documentation] 
Resource: [[Example code - Unit test]] 
Resource: [[Unit test - start of reverse polish notation class]] 

== Subjects covered ==
Overview of test methods 
Unit test using pytest framework.

== Exercises to be handed in ==
You should make a special folder for the exercises. I will refer to my special folder as ''unittest'' in these exercises. You will also see some ''__pycache__'' folders appear in places. This is Pythons cache for "compiled" programs. It is safe to ignore and also to delete, because it may become outdated. 
In some of these exercise you need to hand in not just a single file, but multiple files in a folder hierarchy. Zip the folder structure for your entire solution folder. Make sure it is clear to see what exercise your code/data is solving. And learn to zip :-)
# Use your '''normalize''' function from exercise 3 in [[Functions, namespace, memory management]]. If you did not do so already, change it to use exceptions instead of '''sys.exit()''', when an error occurs. Now make simple unit tests for the following test cases: a list of positive numbers, a list of negative numbers, a list of integers, a list of mixed floats and integers, a single number in the list, empty list, a list with at least one non-number (string, list, set), a set containing numbers, and a dict where the keys are numbers. Get other ideas if you can. The '''normalize''' function and all test functions must be in one single file (''normalize_test.py'' in ''unittest''), which you can run ''pytest'' on. 
# Now remove the '''normalize''' function from ''normalize_test.py'' and put it in its own file ''normalize.py''. Import it from the ''normalize_test.py'' like '''from normalize import normalize'''. The first ''normalize'' is the name of the .py file, the second ''normalize'' is the name of your normalize function. Just run ''pytest'' (no file name) in the folder to check it works. It is more normal to have test and function separated. 
# Above we removed test code from function code by creating two files. Next, put the files in their own folder in ''unittest''. I would put my ''normalize.py'' in ''unittest/src'' and ''normalize_test.py'' in ''unittest/test''. This way there is a very clear separation between function and test. The problem is making sure the test code loads the function code. Do it wrong a couple of times - it is very instructive. 
# Follow the file structure of having a ''code'' (or ''src'') folder for programs, a ''test'' folder for tests, and now a ''testdata'' folder for files containing test data. Now make unit tests and appropriate test data files for your '''fasta''' class from last week. In this exercise you just need to make unit test for the method '''load'''. You need to hand in both tests and test data. 
# Add unit tests for the method '''save''' in your '''fasta''' class. Hand in same way as above. 
# Add unit tests for the method '''delete''' in your '''fasta''' class. Hand in same way as above. 
I would not be surprised if you find errors in your '''fasta''' class based on these tests. I found flaws in my code.

== Exercises for extra practice ==
# Add unit tests for all methods in your '''fasta''' class. That will be a bit of work.

Beginning unit test

2026-04-13T09:50:54Z

WikiSysop: /* Exercises to be handed in */

__NOTOC__
{| width=500 style="font-size: 10px; float:right; margin-left: 10px; margin-top: -56px;"
|Previous: [[Intermediate classes]]
|Next: [[Intermediate unit test]]
|}
== Required course material for the lesson ==
Powerpoint: [https://teaching.healthtech.dtu.dk/material/22118/22118_09-Testing.ppt Testing] 
Online: [https://docs.pytest.org/ pytest documentation] 
Resource: [[Example code - Unit test]] 
Resource: [[Unit test - start of reverse polish notation class]] 

== Subjects covered ==
Overview of test methods 
Unit test using pytest framework.

== Exercises to be handed in ==
You should make a special folder for the exercises. I will refer to my special folder as ''unittest'' in these exercises. You will also see some ''__pycache__'' folders appear in places. This is Pythons cache for "compiled" programs. It is safe to ignore and also to delete, because it may become outdated. 
In some of these exercise you need to hand in not just a single file, but multiple files in a folder hierarchy. Zip the folder structure for your entire solution folder. Make sure it is clear to see what exercise your code/data is solving. And learn to zip :-)
# Use your '''normalize''' function from exercise 3 in [[Functions, namespace, memory management]]. If you did not do so already, change it to use exceptions instead of '''sys.exit()''', when an error occurs. Now make simple unit tests for the following test cases: a list of positive numbers, a list of negative numbers, a list of integers, a list of mixed floats and integers, a single number in the list, empty list, a list with at least one non-number (string, list, set), a set and a dict. Get other ideas if you can. The '''normalize''' function and all test functions must be in one single file (''normalize_test.py'' in ''unittest''), which you can run ''pytest'' on. 
# Now remove the '''normalize''' function from ''normalize_test.py'' and put it in its own file ''normalize.py''. Import it from the ''normalize_test.py'' like '''from normalize import normalize'''. The first ''normalize'' is the name of the .py file, the second ''normalize'' is the name of your normalize function. Just run ''pytest'' (no file name) in the folder to check it works. It is more normal to have test and function separated. 
# Above we removed test code from function code by creating two files. Next, put the files in their own folder in ''unittest''. I would put my ''normalize.py'' in ''unittest/src'' and ''normalize_test.py'' in ''unittest/test''. This way there is a very clear separation between function and test. The problem is making sure the test code loads the function code. Do it wrong a couple of times - it is very instructive. 
# Follow the file structure of having a ''code'' (or ''src'') folder for programs, a ''test'' folder for tests, and now a ''testdata'' folder for files containing test data. Now make unit tests and appropriate test data files for your '''fasta''' class from last week. In this exercise you just need to make unit test for the method '''load'''. You need to hand in both tests and test data. 
# Add unit tests for the method '''save''' in your '''fasta''' class. Hand in same way as above. 
# Add unit tests for the method '''delete''' in your '''fasta''' class. Hand in same way as above. 
I would not be surprised if you find errors in your '''fasta''' class based on these tests. I found flaws in my code.

== Exercises for extra practice ==
# Add unit tests for all methods in your '''fasta''' class. That will be a bit of work.

Beginning unit test

2026-04-13T09:40:22Z

WikiSysop: /* Exercises to be handed in */

Intermediate unit test

2026-04-10T12:07:43Z

WikiSysop: /* Subjects covered */

Intermediate unit test

2026-04-10T12:05:47Z

WikiSysop: /* Exercises for extra practice */