|
Size: 9361
Comment:
|
Size: 10473
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| ## page was renamed from ThesesGuidelines | |
| Line 4: | Line 5: |
| = Guidelines for M.Sc. and B.Sc. theses at the Chair of Algorithms and Data Structures = | This page contains guidelines for writing a Master's or Bachelor's Thesis at the Chair of Algorithms and Data Structures. Here is long list of [[http://ad.informatik.uni-freiburg.de/publikationen/bachelor_master_arbeiten|example theses]] which have already been completed at our chair. |
| Line 8: | Line 9: |
| == Examples == | = Elements of a thesis = |
| Line 10: | Line 11: |
| All M.Sc. or B.Sc. theses primarily supervised so far by our chair can be found under http://ad.informatik.uni-freiburg.de/publikationen/bachelor_master_arbeiten . The list is currently (01Apr14) still quite incomplete, but that will hopefully change within a week from now. | M.Sc. and B.Sc. theses are supposed to be pieces of scientific work. Here are some guidelines on the typical elements of such work. |
| Line 12: | Line 13: |
| == Content == M.Sc. and B.Sc. theses are supposed to be pieces of scientific works. Here are some guidelines to some minimal standards required of any scientific work so that it deserves that name. === Title === |
== Title == |
| Line 20: | Line 17: |
| === Abstract === | == Abstract == |
| Line 22: | Line 19: |
| An abstract should be self-contained and understandable also to a non-expert. ''Think of it as the shortest way to say what you did in one paragraph.'' As a minimum, it should clarify the problem dealt with in the thesis, and the main results that were obtained. Optionally, you can add a sentence or two about the underlying techniques and how the thesis advances the state of the art. | An abstract should be self-contained and understandable to a non-expert. ''Think of it as the shortest way to say what you did in one paragraph.'' As a minimum, it should clarify the problem dealt with in the thesis, and the main results that were obtained. If a short example can be given, it should be given, but this is not always possible. If space permits, add a sentence or two about the underlying techniques and how the thesis advances the state of the art. |
| Line 24: | Line 21: |
| === Introduction === | == Introduction == |
| Line 28: | Line 25: |
| === Related Work === | One common mistake (and nuisance) is to have relative vague and informal statements in the introduction and then later a separate section with a more formal problem statement. The corresponding reader experience is that upon first reading one either does not understand the introduction or does not find it very useful or both. You can fix this as follows: whatever is relatively easy to understand and can already be defined in the introduction should already be defined in the introduction. |
| Line 30: | Line 27: |
| Most probably, other researchers have worked on the problem of your thesis, or a strongly related problem, before. ''Your thesis should include a section which summarizes the most relevant of these works.'' Typically this is Section 2, right after the introduction. For each of these works, it should be explained in a nutshell what they do, what they achieve, and how this differs from what you do in your thesis. This should be understandable without the need to actually read the paper. Think of each description as the shortest way to say this in one paragraph. When there is a lot of work about a particular topic / problem, it is ok to focus on the most recent / most advanced approaches. | == Related Work == |
| Line 32: | Line 29: |
| === Theoretical analysis === | Most probably, other researchers have worked on the problem of your thesis, or a strongly related problem, before. ''Your thesis should include a section which summarizes the most relevant of these works.'' Typically this is Section 2, right after the Introduction. For each of these works, it should be explained in a nutshell what they do, what they achieve, and how this differs from what you do in your thesis. This should be understandable without the need to actually read the papers referred to. For each related work, think of the description as the shortest way to say this in one paragraph. |
| Line 34: | Line 31: |
| Most probably, your work will make use of some algorithms and data structures. Either your own, or such from previous work, or a combination of the two. ''In any case, provide information about the basic complexity of your algorithms, in particular their running time.'' Do this also if the the statement appears straightforward to you. For example, your algorithm may obviously be linear in the size of the input data. Anyway, say it! If the asymptotic complexity is not obvious, provide a proof if possible. | When there is a lot of work about a particular topic / problem, it is ok to focus on the most recent / most advanced approaches. Where there is no work on the exact problem from your thesis, the Related Work section should be about work on similar problems and it should explain how these related problems differ. Note that sometimes a problem looks different only on the surface, and the solutions can actually be applied to your problem as well. |
| Line 36: | Line 33: |
| === Empirical analysis === | == Theoretical analysis == |
| Line 38: | Line 35: |
| Most probably, your work involves the implementation of an algorithm or data structure, or of a whole system. ''Whatever it is, your implementation should be thoroughly evaluated.'' The kind of evaluation depends on the nature of your problem. If the focus is on results of a particular ''quality'', that should be evaluated. If the focus is on ''efficiency'', running time and (if relevant) space consumption should be evaluated. Even if the focus is on quality, efficiency should be evaluated, too. One always want to know the running time of a procedure and (if relevant) its space consumption. If there is a pre-processing phase, this should be evaluated seperately. If the pre-processing consumes a lot of intermediate disk space or memory, that should also be evaluated. Think about the evaluation from the perspective of someone who wants to use your software in practice. What is it that you would want to know then? | Most probably, your work will make use of some algorithms and data structures. Either your own, or such from previous work, or a combination of the two. ''In any case, provide information about the basic complexity of your algorithms, in particular their running time.'' Do this also if the the statement appears straightforward to you. For example, the running time of one of your algorithms may obviously be linear in the size of the input data. In any case, say it and provide an argument / proof for it! |
| Line 40: | Line 37: |
| Typically, there are other approaches which can be used (either directly or with small modifications / adjustments) to solve your problem. As a minimum, compare to the best one of these approaches. If there is a variety of principally different approaches, pick the best one for each principle. If there is no solution yet for your problem, think of a simple baseline algorithm (= the straightforward solution) and compare to that. Do your evaluation on at least three different data sets of different kinds and sizes. | == Empirical analysis == |
| Line 42: | Line 39: |
| === Future work === | Most probably, your work involves the implementation of an algorithm or data structure, or of a whole system. ''Whatever it is, your implementation should be thoroughly evaluated.'' The kind of evaluation depends on the nature of your problem. If the focus is on results of a particular ''quality'', that should be evaluated. If the focus is on ''efficiency'', running time and (if relevant) space consumption should be evaluated. Even if the focus is on quality, efficiency should be evaluated, too. One always wants to know the running time of a procedure and (if relevant) its space consumption. If there is a pre-processing phase, this should be evaluated separately. If the pre-processing consumes a lot of intermediate disk space or memory, that should also be evaluated. Think about the evaluation from the perspective of someone who wants to use your software in practice. What is it that you would want to know then? |
| Line 44: | Line 41: |
| Most probably, your work will leave various open ends. Make a list of what could be done next to improve on what you did. For each item, give a short description of the possible improvement + an idea for how, in principle, it could be achieved. Also give an estimate for the necessary time to realize that improvement (hours, days, weeks, months). Order your list by importance / significance = the thing that should be improved next / gives the biggest improvement should come first. | Typically, there are other approaches which can be used (either directly or with small modifications / adjustments) to solve your problem. As a minimum, compare to the best one of these approaches. If there is a variety of principally different approaches, pick the best one for each principle. If there is no solution yet for your problem, think of a simple baseline algorithm (= the straightforward solution) and compare to that. Sometimes there are two or even three simple baseline algorithms. Do your evaluation on at least three different data sets of different kinds and sizes. If the amount of work needed per data set is very large, it is OK to use only two data sets. |
| Line 46: | Line 43: |
| == Writeup == | == Future work == |
| Line 48: | Line 45: |
| === English or German === | Most probably, your work will leave various open ends. Make a list of what could be done next to improve on what you did. For each item, give a short description of the possible improvement + an idea for how, in principle, it could be achieved. Also give an estimate for the necessary time to realize that improvement (hours, days, weeks, months). Order your list by importance / significance. That is, the thing that should be improved next / gives the biggest improvement should come first. = How to write = == English or German == |
| Line 52: | Line 53: |
| === Scope === | == How much == |
| Line 54: | Line 55: |
| A typical question is: how much should I write? My typical answer is: write as much as is necessary to understand what you did, how you were doing it, and all the aspects listed in Section "Content" above. No more, no less. The thesis should be self-contained. That is, for someone with general basic knowledge in computer science, it should not be necessary to read anything else than your thesis in order to understand your descriptions / explanations on the named aspects. | A typical question is: how much should I write? My typical answer is: write as much as is necessary to understand what you did, how you were doing it, and all the aspects listed in Section "Elements of a thesis" above. No more, no less. The thesis should be self-contained. That is, for someone with a basic education in computer science, it should not be necessary to read anything else than your thesis in order to understand all the main aspects of your thesis. |
| Line 56: | Line 57: |
| === Style === | == How artistic == |
| Line 58: | Line 59: |
| The most important general rule is: write simple sentences. A simple sentence has the form: subject, predicate, object. If your sentences has two or more verbs, consider splitting it into two simpler sentences. It is rarely necessary to have sentences with more than two verbs. The sentences in this paragraph are a good example for this writing style. Note that this writing style may not be the best when writing a novel. But it is perfect for scientific text, because it is easy to read and follow. | The most important general rule is: write simple sentences. A simple sentence has the form: subject, predicate, object. If your sentences has two or more verbs, consider splitting it into two simpler sentences. It is rarely necessary to have sentences with more than two verbs. The sentences in this paragraph are good examples for this writing style. Note that this writing style may not be the best when writing a novel. But it is perfect for scientific text, because it is easy to read and follow. |
| Line 60: | Line 61: |
| Structure is also very important. A good way to start your write-up is to write down all the section and subsection headers. The names should be carefully chosen, and they should be consistent in their style. | Structure is also very important. A good way to start your write-up is to write down all the section and subsection headers. The names of the headers should be carefully chosen, and they should be consistent in their style. |
| Line 62: | Line 63: |
| Every section and every subsection should start with a small introduction that tells the reader what comes next. The following four sentences are an example. In this section, we will give a high-level description of the algorithm. The algorithm has two phases. In the first phase, ... (Section 3.1). In the second phase, ... (3.2). Again, note how simple the sentences are. | Every section and every subsection should start with a small introduction that tells the reader what comes next. The following four sentences are an example: "In this section, we will give a high-level description of the algorithm. The algorithm has two phases. In the first phase, ... (Section 3.1). In the second phase, ... (3.2)." Again, note how simple the sentences are. |
| Line 64: | Line 65: |
| Consistency is also very important. If you use a particular word to describe something, stick to that word. Variation is maybe nice in a novel. But in scientific work, every single inconsistency makes it harder for the reader. It is also fine to repeat the same word again in the next sentences. In scientific work, it is even good style. Visual consistency is also important. If you use different fonts, use them with a consistent ``semantics''. If you have a variety of tables, make sure they have a consistent look. | Consistency is also very important. If you use a particular word to describe something, stick to that word. Variation is maybe nice in a novel. But in scientific work, every single inconsistency makes it harder for the reader. It is also fine to repeat the same word again in the next sentences. In scientific work, it is even good style. For example, in the previous paragraph, it it better to write "The algorithm has two phases" than just "It has two phases". Visual consistency is also important. If you use different fonts, use them with a consistent meaning. If you have multiple tables or figures in your thesis, make sure they have a consistent look. |
| Line 66: | Line 67: |
| === Bibliography === | == Bibliography == |
| Line 70: | Line 71: |
| == Topic of your own choice or with a company == | == Typical errors == |
| Line 72: | Line 73: |
| It's certainly possible to do a master's thesis with a topic of your own choice. Some students also want to write their thesis at a company and want Prof. Bast to be their reviewer. In both of these cases, it is particular important that the work adheres to the scientific standards sketched above. |
Please avoid at least the following errors. |
| Line 76: | Line 75: |
| If you plan such a thesis and want Prof. Bast to be your reviewer, please send her an email with succinct answers to the following quesions: | ''Hyphens in noun phrases'': multi-word noun phrases have a hyphen only if you use them as an adjective. Here is an example: (1) This problem has a large scale. (2) This is a large-scale problem. Putting a hyphen in (1) would be a mistake. Not putting the hyphen in (2) would be a mistake. Understand the purpose of the hyphen. It says what belongs together. In sentence (2), without the hyphen, it would not be clear whether it is a "scale problem" that is large, or whether the problem has a "large scale". |
| Line 78: | Line 77: |
| 1. What is the expected / aimed at outcome? | ''Commas after introductory clauses'': there is always a comma after clauses like "However", "In this section", "Therefore", ... |
| Line 80: | Line 79: |
| 2. How does your approach and the expected result differ from the state of the art? See Section Contents -> Related Work above. | TODO: what else? |
| Line 82: | Line 81: |
| 3. How do you plan to evaluate your work. See Section Contents -> Theoretical Analyis / Empirical Analysis above. | == Spelling == |
| Line 84: | Line 83: |
| Please don't send pages of text. Please be specific though. The answers should make it possible to assess what your thesis is about and whether it fulfills our standards. No more, no less. | As a final step, ALWAYS run a spell checker over your write-up. It is very embarrassing indeed if your write-up contains mistakes that any spell checker would have found. TODO: spell-check this web page. |
This page contains guidelines for writing a Master's or Bachelor's Thesis at the Chair of Algorithms and Data Structures. Here is long list of example theses which have already been completed at our chair.
Contents
Elements of a thesis
M.Sc. and B.Sc. theses are supposed to be pieces of scientific work. Here are some guidelines on the typical elements of such work.
Title
As a minimum, a title should be informative. Think of it as the shortest way to say what you did in one short sentence. A secondary criterion is that it is catchy. This is not necessary, however, and sometimes hard to achieve. Also a catchy title should be informative. If you build a system, a typical title is the name of the system, followed by a colon, followed by a short description of what the system does.
Abstract
An abstract should be self-contained and understandable to a non-expert. Think of it as the shortest way to say what you did in one paragraph. As a minimum, it should clarify the problem dealt with in the thesis, and the main results that were obtained. If a short example can be given, it should be given, but this is not always possible. If space permits, add a sentence or two about the underlying techniques and how the thesis advances the state of the art.
Introduction
An introduction should be self-contained and understandable to a non-expert. Think of it as the shortest way to say what you did in a couple of pages. As a minimum, it should clarify the problem dealt with, the motivation for dealing with that problem, the main results, the main challenge and the line of attack used to overcome it, and how it advances the state of the art. In the abstract, you have only one or two sentences (if any) for each of these aspects. In the introduction, you have more space. For the problem statement, it is almost always a good idea to provide a figure or screenshot with a (carefully chosen) example.
One common mistake (and nuisance) is to have relative vague and informal statements in the introduction and then later a separate section with a more formal problem statement. The corresponding reader experience is that upon first reading one either does not understand the introduction or does not find it very useful or both. You can fix this as follows: whatever is relatively easy to understand and can already be defined in the introduction should already be defined in the introduction.
Related Work
Most probably, other researchers have worked on the problem of your thesis, or a strongly related problem, before. Your thesis should include a section which summarizes the most relevant of these works. Typically this is Section 2, right after the Introduction. For each of these works, it should be explained in a nutshell what they do, what they achieve, and how this differs from what you do in your thesis. This should be understandable without the need to actually read the papers referred to. For each related work, think of the description as the shortest way to say this in one paragraph.
When there is a lot of work about a particular topic / problem, it is ok to focus on the most recent / most advanced approaches. Where there is no work on the exact problem from your thesis, the Related Work section should be about work on similar problems and it should explain how these related problems differ. Note that sometimes a problem looks different only on the surface, and the solutions can actually be applied to your problem as well.
Theoretical analysis
Most probably, your work will make use of some algorithms and data structures. Either your own, or such from previous work, or a combination of the two. In any case, provide information about the basic complexity of your algorithms, in particular their running time. Do this also if the the statement appears straightforward to you. For example, the running time of one of your algorithms may obviously be linear in the size of the input data. In any case, say it and provide an argument / proof for it!
Empirical analysis
Most probably, your work involves the implementation of an algorithm or data structure, or of a whole system. Whatever it is, your implementation should be thoroughly evaluated. The kind of evaluation depends on the nature of your problem. If the focus is on results of a particular quality, that should be evaluated. If the focus is on efficiency, running time and (if relevant) space consumption should be evaluated. Even if the focus is on quality, efficiency should be evaluated, too. One always wants to know the running time of a procedure and (if relevant) its space consumption. If there is a pre-processing phase, this should be evaluated separately. If the pre-processing consumes a lot of intermediate disk space or memory, that should also be evaluated. Think about the evaluation from the perspective of someone who wants to use your software in practice. What is it that you would want to know then?
Typically, there are other approaches which can be used (either directly or with small modifications / adjustments) to solve your problem. As a minimum, compare to the best one of these approaches. If there is a variety of principally different approaches, pick the best one for each principle. If there is no solution yet for your problem, think of a simple baseline algorithm (= the straightforward solution) and compare to that. Sometimes there are two or even three simple baseline algorithms. Do your evaluation on at least three different data sets of different kinds and sizes. If the amount of work needed per data set is very large, it is OK to use only two data sets.
Future work
Most probably, your work will leave various open ends. Make a list of what could be done next to improve on what you did. For each item, give a short description of the possible improvement + an idea for how, in principle, it could be achieved. Also give an estimate for the necessary time to realize that improvement (hours, days, weeks, months). Order your list by importance / significance. That is, the thing that should be improved next / gives the biggest improvement should come first.
How to write
English or German
You can write your thesis in German or in English. If you write it in English, more people will read it. Plus, it's a great opportunity to practice writing in English. You will almost certainly need that ability in your later job, so why not start now. If you don't want anyone to read your thesis, write it in French.
How much
A typical question is: how much should I write? My typical answer is: write as much as is necessary to understand what you did, how you were doing it, and all the aspects listed in Section "Elements of a thesis" above. No more, no less. The thesis should be self-contained. That is, for someone with a basic education in computer science, it should not be necessary to read anything else than your thesis in order to understand all the main aspects of your thesis.
How artistic
The most important general rule is: write simple sentences. A simple sentence has the form: subject, predicate, object. If your sentences has two or more verbs, consider splitting it into two simpler sentences. It is rarely necessary to have sentences with more than two verbs. The sentences in this paragraph are good examples for this writing style. Note that this writing style may not be the best when writing a novel. But it is perfect for scientific text, because it is easy to read and follow.
Structure is also very important. A good way to start your write-up is to write down all the section and subsection headers. The names of the headers should be carefully chosen, and they should be consistent in their style.
Every section and every subsection should start with a small introduction that tells the reader what comes next. The following four sentences are an example: "In this section, we will give a high-level description of the algorithm. The algorithm has two phases. In the first phase, ... (Section 3.1). In the second phase, ... (3.2)." Again, note how simple the sentences are.
Consistency is also very important. If you use a particular word to describe something, stick to that word. Variation is maybe nice in a novel. But in scientific work, every single inconsistency makes it harder for the reader. It is also fine to repeat the same word again in the next sentences. In scientific work, it is even good style. For example, in the previous paragraph, it it better to write "The algorithm has two phases" than just "It has two phases". Visual consistency is also important. If you use different fonts, use them with a consistent meaning. If you have multiple tables or figures in your thesis, make sure they have a consistent look.
Bibliography
Make sure that the entries in your bibliography have a consistent style. That is, abbreviate all conferences in the same way or use the full names for all, but do not mix the two styles. Same for author names. Same for capitalization of titles. Same for page numbers. It makes a very careless and untidy impression, if the bibliography entries are inconsistent in their style.
Typical errors
Please avoid at least the following errors.
Hyphens in noun phrases: multi-word noun phrases have a hyphen only if you use them as an adjective. Here is an example: (1) This problem has a large scale. (2) This is a large-scale problem. Putting a hyphen in (1) would be a mistake. Not putting the hyphen in (2) would be a mistake. Understand the purpose of the hyphen. It says what belongs together. In sentence (2), without the hyphen, it would not be clear whether it is a "scale problem" that is large, or whether the problem has a "large scale".
Commas after introductory clauses: there is always a comma after clauses like "However", "In this section", "Therefore", ...
TODO: what else?
Spelling
As a final step, ALWAYS run a spell checker over your write-up. It is very embarrassing indeed if your write-up contains mistakes that any spell checker would have found.
TODO: spell-check this web page.