Master ST Home
Center ST Home
FAQ
Contact
Brochure
Introduction
Area
Center
Curriculum
Pre-master
Supervision
Thesis Projects
Career
International Exchange
People
Students
Staff
Coordinators
Courses
FPLC
|
SWE
DOS
|
SWS
CCO
|
SWA
APA
|
AFP
|
DBA
PV
|
GP
Seminars
DTP
|
TBPA
ACC
|
NO
DBA
Other Activities
Literature Study
Colloquium
Experimentation Project
Thesis project
How To
Electronic Library
?
Research Talk
Use TeX
Formulate Effectively
CommonMistakes
(constr)
Center
Home
Courses
People
Projects
Page
Edit Page
Rename Page
Attach File
Printable
Wiki Source
More ...
Web
Recent Changes
Notify Service
News
Page Index
Search
More ...
Wiki
About TWiki
Text Formatting
Registration
Change Password
Reset Password
Users
Groups
Log In
or
Register
Common Mistakes
Master
On this page we will list some common mistakes made by students in their theses. %TOC% ---++ Explanation Structure The following fragment is taken from a partially uncorrected thesis: <pre> The majority of type inference systems today are an extension of Hindler- Milner[19]. HML[13] by Daan Leijen is no different in this regard. It extends Hindley-Milner to add support for first class polymorphism. HML is itself an simplification and at the same time a restriction of MLF[20] while retaining the expressiveness of MLF. HML in contrast to MLF only uses so called flexible types, which make the system easier to used compared to MLF. The only annotation needed in HML on function parameters with a polymorphic type (Another version HMLF allows annotations of Let bindings). Because of this conservative annotation requirement and because HML is an extension of HM any program that is well typed in Hindley-Milner is well typed in HML. </pre> ---+++ Define before use As in programming concepts need to be known before they can be used. So concepts are to be introduced by an author (a declaration) or assumed to be known by the reader (i.e. imported). The above text uses the concept 'Hindley-Milner' (a type system), which for this particular thesis is safe be assumed to be known. However, the concept 'MLF' (also a type system) is not introduced, highly special for this field of research and it thus it is unsafe to assume it to be known. The definition of 'MLF' can be given in a formal way or more informal. The choice between the form of an introduction of a concept depends on its intended use later in the writing. A formal definition would look like the following, usually giving components, conditions, relationships, etc. <pre> Definition 2.6: A type system MLF is a .... (X,Y,...) where X is a ... and Y a ... </pre> A less formal definition could use refine another concept, be introduced using an example, or explicitly list (known) aspects in which it differs: * *Refinement*: The type system MLF is a ... where ... * *Example*: The type system MLF accepts more than ..., for example the following program fragment ... is accepted by MLF but not by ... * *Differing aspects*: The type system MLF differs from the Hindley-Milner type system in that it deals with higher-ranked types. ---+++ Visually emphasize important introduced concepts A defined concept may easily get lost if introduced in the midst of larger chunks of text. Emphasize it, and for larger writings include it in an index. ---+++ Be specific The following definitions are increasingly specific: * MLF is an extension of Hindley-Milner. * MLF extends Hindley-Milner with higher-ranked types. * MLF extends Hindley-Milner with higher-ranked types and a way to deal with lack of principality by delaying the choice required for principality to the moment a type is instantiated. How much information needs to be conveyed depends on the writing, but the pitfall is to provide almost zero information as in the first of the above alternatives. Better leave it out or be specific. More examples: * '... using the tool uuagc' does not tell what uuagc does, but '... using the attribute grammar system compiler uuagc' tells in 3 additional words what the system does, of course given the assumption that the additional words are known by the reader. ---+++ Be type correct and consistent Mention the type of a concept, for example the 'Hindley-Milner type system' instead of only 'Hindley-Milner'. For a list of items, follow as much as possible the same sentence structure for each item. If this cannot be done it usually is an indication that the items do not belong to the same list. Similarly, an item must refer to the same 'thing', i.e. be type correct and consistent. Again, if not possible, don't put the items in the same list. ---+++ Be precise It is a pitfall to almost explain it correctly, or worse, combine a bunch of words together without checking if it really means what you want it to mean. This is highly specific for a particular field of research, but still some examples: * 'higher-rank polymorphic type inferencing algorithm' means that the algorithm itself is higher-ranked and polymorphic, which is a property which only can hold for a type, not for an algorithm. It should have been something like 'a type inference algorithm for a type system involving higher-ranked polymorphism'. Again, this ties in to the notion of type correct writing. ---+++ Tell a story, make a point, go from something to something On every level there is an introduction + reasoning + conclusion, otherwise there is no point in including it in the type of writing academics produce. This holds for a thesis as a whole, an individual chapter, and single paragraphs. A template-like artificial example of this on the paragraph level is the following: <pre> As seen from ... it is clear that X. However, ... shows that X does not always, in particular the following ... . We therefore see that Y holds. </pre> The paragraph builds on something 'X', reasons about it, finds a fault, an exception, or whatever is appropriate for the story and then concludes with something 'Y'. A subsequent paragraph can then take this 'Y' as a starting point. ---+++ Break a mutual dependency by a forward reference. Not always a definition can be placed before its first use. This usually means that definitions are mutually related, e.g. by using eachother in their definitions. It also may be the case that for other reasons (e.g. it better fits in explanation) that a concept is first used, e.g. by using an example of the concept, and then later on introduced. In such cases include a forward reference to the place of the definition, or mention that first examples are given, or mention that later a definition + more explanation follows. ---+++ You are not the reader: take distance from being a writer, read as if you are a first time reader Probably the most difficult of writing is that after a while you (1) become blind to the all the mistakes you make and (2) you know the topic so well that you cannot imagine the reader does not so. For your writing to be readable you must proofread it as if you do not know about your own writing. Letting somebody else review it helps, but often a reviewer is not available. So, ideally you can take distance by not looking at your writing for some time, and then meticulously read it as if you were a first time zero knowledge reader which will complain about any pitfall mentioned here. ---++ Sentence Structure ---+++ Do not glue two separate sentences together with a comma * The comma in the sentence: _At this time researchers have a clear understanding about the possibilities a processor offers them, the only thing now is that programmers should introduce special instructions in their code to invoke these processor optimizations._ should be replaced by _and_ or be the end of the first sentence. If the second sentence follows somehow from the first one, you may use words like _thus_, or terminate the first part with a ";". ---++ Mode ---+++ State things in a positive way Try to avoid *would*, *could*, *should*, *might* etc. using such words a lot gives the reader the impression you do not even believe yourself what you are writing. <hr> last updated: -- Main.AtzeDijkstra - 08 Apr 2011