On this site:

Home
Publications
NLP
MAS
Teaching
Contact


Other links:

Thesis how-to's
Journals
AI papers
Citations
Conferences
AI at AAAI
AI in CS
AI videos @ SRI
comp.ai.*
Comp.ai FAQ
 
  

Hints for research students

This page was designed to provide computer science students with basic tips and tricks for their research project. If you are one of these, we hope that these tips will be very useful to you.

Contents


Before we start, take a look at these two papers. They will answer a lot of the fundamental questions on how to write a thesis or conduct research. Then we will add some more tips on topics that these articles do not tackle. At the end of this page, you will find links to other student help pages, search engines that are not mentioned in the text etc.

Starting a Research Project

  • Draft a workplan as soon as possible and try to keep within the schedule. A work plan is never final: change it when you need to. It's main purpose is to give feedback on how long you will still need and to stop you from being too detailed at the beginning and dropping important issues at the end due to a deadline. Get all changes to your workplan checked with your supervisor.
  • Locate review articles. Review articles summarize whole research areas and show how the most important topics in a field are related to each other and what current research topics are. They are an efficient time saver. First, because you will easily get the most important references and second, because they contain most of the material you will need for your "related work" section of your thesis.
  • Find out what are the most important conferences in your field.
    There are several ways to accomplish this: asking your advisor, reading the reference sections of the papers he/she handed you, doing a search on the web, or searching the library (but asking a supervisor is usually sufficient). The single most important advantage of using the web is that there is a very high probability that someone has already compiled links on the topic.
  • Scan the recent proceedings of these conferences carefully for related work.
    Not only will you know the 'state of the art' in your field but comparing the reference sections of different papers will give you an idea of which one are the most important ones: the more often a paper shows up, the more essential it is that you have read it.
  • Check out the home pages of the authors and their institutions.
    Keep in mind that papers are usually written almost a year before they actually make it to print. The most recent information is often found on the web pages of the people or institutions.
  • Write down your ideas while reading, because the "oh, I won't forget this one" does not work. Think about how to store these ideas and how you can retrieve them. Sketching on paper and later elaborating them with a word processor that has a "find" function is usually a good idea. Use diagrams whenever possible. Experience shows that you will be using them over and over again. Drafting them early on saves a lot of work later.
  • Find out which resources you can access. What resources do you need and cannot do without? E.g. if you do not have access to necessary hardware, you should think of an alternative way to do the practical part of your project as early as possible.

Reading Related Work

Once you have worked out what is currently going on in your field, you might want to check some other publications. Either consult the respective homepages or use search engines (e.g. www.scienceindex.com, or a bibliography data base). Don't forget the NECI Scientific Literature Digital Library for computer science research papers. It allows Boolean keyword searches -- including title, author, reference, URL tags and the contents of pdf/ps files (!)-- that it has found on the Web. Additionally, check out the workshops that are held at the big conferences (a schedule for national and international conferences can be found at the Gesellschaft für Informatik). Another good point to check for current research are journals (Elsevier offers an online search for all their journals, if you need navigation aid for AI literature, check the ranking of AI journals, which is based on the science index from the Institute for Scientific Information). In this context, you may want to try this site on critical reading.

Although you are a very intelligent and creative person, people in the research community are very likely to have thought of similar problems and solutions as you do. They are also very likely to have not thought of exactly the same problems and the same solutions as your have. The similarities and differences are a very thoughtful source of new ideas. An hour reading is an hour well spent.

However, finding the right literature is a challenging task. A very good starting point are the proceedings of most important conferences in your field. If you can make out prominent researchers in your field, look for others that cite them.

Also try to find review papers of the related fields. Finding related fields can be somewhat difficult. Strategies for finding them include: browse web indices like Yahoo!, ask yourself what your results could be used for and look for the corresponding fields, or you can attend a workshop/ conference where people will tell you.

Writing a Scientific Text

We strongly recommend that you do not start writing at the computer. Always draft your ideas on paper. This is not old fashioned, you will use a modern word processing system later. However, the change of the medium from draft to final version forces you to think through your main ideas once more. Drafting using a computer does not do this. Many times we discovered new ideas in our own drafts that appeared to be in there but of which we had not thought when writing them down for the first time.

Do not underestimate the value of backups, both of your paper drafts and your text files on the computer. We recommend that you back-up on at least four levels:

  • Editor: make sure that you use the backup features of your editor.
  • quick backup. Create an easy to use and fast way of backing up your working directory. This procedure should be so easy that your can start it in the background while working without need to think about it.
  • long term backup (zip, preferably a different hard drive or even a on floppy discs)
  • remote (a different machine).

Not only will this help you in an emergency. It will also make you feel safe so you do not have to worry about the odd system crash.


Writing a paper

Once you have achieved progress in your work, try to find a conference or workshop where you can publish your findings/ideas. Mailing lists are usually the best means to learn about "call for papers". Once you have found a place where to publish, you need to think of how to write your ideas up. If you want to make sure your effort is not crushed by the referees, check who is in the program committee. Truth to be known, they will check if you have read their work and you should make sure that you know how their work relates to yours. But there is also another important reason to look at their work: if you submit something to their workshop you are very likely to be doing something similar to their work. There is nothing more embarrassing than finding out that they already have done something similar, without you noticing it!

Some other rules of thumb that may help you getting your paper accepted:

  • Ask colleagues to proof-read it.
  • Check for consistent names for your concepts.
  • Check the spelling, duh
  • Check the logical structure (often, the way you actually came up with the results is not the most logical way to present them).
  • Do not devote too much space too well known facts.
  • Make sure your new findings are prominently placed.

Using TeX for word processing

In your Linux installation you will find (in my SuSE 6.2 at any rate):
  • /usr/info/latex.info.gz -- which you access via the console with the command "info" or in Emacs via "C-hi"; this is a list of most of the latex commands, with brief descriptions.
  • /usr/share/texmf/doc/ -- a directory containing docs for the various packages such as the graphics package for including EPS files (/usr/share/texmf/doc/latex/graphics/grfguide.ps)
On the web you find:

Style and Layout for a paper

  • Title: Capitalise the first letter of nouns, pronouns, verbs, adjectives, and adverbs; do not capitalize articles, coordinate conjunctions, or prepositions (unless the title begins with such a word).
  • Use examples and Figures whenever possible, when in doubt: use it.
  • Use paragraphs to split your text according to its logical structure: one line of reasoning should not be spread over too many paragraphs, arguments not related to one another may not be in the same paragraph.

How to cite

There are many styles you can use to cite works of other authors in different disciplines and even in computer science there is no commonly accepted style. E.g. works can be cited using keys in the folloging styles: [RUNO95], [1] and (Russell and Norvig, 1995). We recommend the latter, as it allows the reader to easily recognise the referred work without need to look up the keys in the references section.
Be aware that it is considered bad style to use the key as the subject of your sentence, rather use the key at the end of the sentence like in "it has often been claimed that ... (e.g. Russell and Norvig, 1995)". If you need to refer to the authors in your text, use phrases like: "as Russell and Norvig (1995) state, ...", where the year of publication is put in brackets and placed right after the occurence of the author's names.
In your references section you list your references alphabetically by the first authors last name. For different kinds of publications, different rules apply for how to provide the information to retrieve that publication. However, every entry starts with the extended key (authors last names, abbreviated first names) and is followed by the publiation year in brackets. Remember to highlight (by using italics) the most important part of the citation, which is not the title of the work itself, but the title of "the thing that rests on the shelf". Thus, for an article in a book, you do not highlight the title of the article, but the title of the book. Which is a complicated way of saying what you can easily see when you look at the following examples:

Book:
  • Russell, S. and Norvig, P. (1995). Artificial Intelligence: A Modern Approach. Prentice Hall International.
Article in a book:
  • Castelfranchi, C. (1992). No More Cooperation, Please! In Search of the Social Structure of Verbal Interaction. In Ortony, A. et al. (eds.): Communication from an Artificial Intelligence Perspective, Springer Verlag, pp. 206-227.
Article in a journal:
  • Russell, S. (1997). Rationality and Intelligence. Artificial Intelligence, vol. 94, pp. 57-77.
Thesis:
  • Beaudoin, L. (1994). Goal Processing in Autonomous Agents. PhD Thesis, School of Computer Science, Universtiy of Birmingham.
For the bibtex users among you (and you should make use of bibtex if you use latex), very similar styles are the kluwer academic publishers' style or AAAI's style (be careful with copyright restrictions here).

Presenting a paper

If you present your work at a conference, spend only very little time on presenting the results themselves. People are usually more interested in models and techniques rather than your actual results. So give only a gist of your results. Remember that you have only little time to present your ideas. Make this time most interesting to advertise your paper.If people doubt your findings, you can tell them about the results in the discussion afterwards (or they can read the paper).

Remember that your presentation is about getting input on your project, it is not about becoming famous (that may happen later, when you get your Nobel prize ;-). The computer science community is expanding, so it will take some time and persistance to make your name and your ideas known.

Keep in mind that you have usually between 20 and 25 minutes for your presentation, with 10 to 5 min left for discussion. This is handled very rigidly so practicing/timing is crucial. Discussion is maybe the most important part of your presentation: you can gather information, convince skeptics, and also establish contact with other people. So, try to think up hypothetical questions and answers to them; it's also a good idea to know related work.

Last but not least: humor is a very good catalyst for attention and absorbtion of new information. Putting in some funny remarks or examples might help you in keeping the audience awake and making them understand. However, beware of artificial funniness!


Designing OHP slides

Many errors can be made when designing slides. Following these guidelines will prevent you from making the most obvious ones. And you join a great community: These guidelines stem from the organizing commitee of the International Joint Conference on Artificial Intelligence and are identical to the guidelines form the American Association for Artificial Intelligence.

  • Use a font lager than 20point.
  • Do not use more than 20-30 characters per line.
  • Leave a margin on all sides of at least one inch.
  • Do not use more than 5-6 lines of text.
  • To check your slides, print them and make sure that you can read them from a distance of at least 2m (6 ft).
A Sans Serif font is recommended, as it will be more legible. Each slide should have a title and a page number. If possible, include the total number of pages as well (in "3/12" style). This helps the audience to track the progress of the talk and people can make notes refering to a specific slide (it is a lot more helpful if people ask "can you put on again slide 3", instead of "can you put on the slide you had in the middle of your talk with these five keywords", right?). As for the design, do not make it too fancy; people might infer that the design is used to cover flaws of the content. Try to fit only one chunk of information on a single slide: people tend to read ahead while you talk, and putting too much on one slide will make them miss your explanation of the first point. Generally, it is a good idea to structure your slides as follows:
  • title (what your talk is about)
  • problem (you are addressing)
  • solution (you are proposing)
  • conclusion (impact of your findings)
If you have only little time for your presentation, include no overview. The overview usually presents nothing new to your audience: they know the title of the talk and they assume that you present your ideas using the above structure. Rather you should tell your audience while you go through the talk what they can expect next and what you have achieved so far. This way, you make up the table of contents while you go along. The slide with the conlusion might reflect this. Reminding your audience what you have talked about so far, supports understanding. Telling them what comes next is a good introductory note when putting up a new slide. Having said this, we also admit that the structure also depends to some extend on the contents of your slides.

In any case, you should make sure that you have enough time to exercise your talk. Experience shows that you should plan for 2 to 3 minutes per slide, but this also depends on the content of the slides. If you have excercised the talk two or three times with the correct timing and without any major mistakes, you will feel a lot more comfortable and your audience will be thankful for a well prepared presentation. One last note: only a handful of speakers are so experienced that they do not use any notes for helping them out during the talk. It is usually a good idea to have the important keywords, the structure of your talk and the most important points you want to make in a written form with you. We recommend you use little palm-sized cards for such notes: it's easy for you to handle them during your talk (you will need one free hand for your slides or the computer) and they suffice to help you out in case you forgot what you wanted to say next.





On these cards you indicate the order of the points you want to make (remember that you exercise the talk a couple of times, so you know most of your points already by heart). You also write down difficult but important sentences and phrase, so you have them ready if you do not get it right at the time you are presenting. In case you do not need the cards for a number of slides, but need to go back to it, it is useful to have the slide number on the card, so you can find the right card quickly. Also write down a numbering of your cards (just in case you drop them ;-). For more details and a procedure on how to develop the contents of you presentation look at Markus Roggenbachs tips and Wolfang Coys tips (german).

Programming

Before you start thinking of how to do the practical part of your thesis, we suggest you think again about what is feasible: do you have access to the right hardware? Which effort is absolutely necessary (workload usually increases unexpectedly during the project, so keep open spaces in your initial schedule)? You should also try to become as independend as possible from certain platforms, hardware, software. Otherwise your project becomes accident-prone and you may spend a lot of time waiting for someone to fix something without being able to do anything useful. Also reflect the following note:
Programming is not hacking. Get used to splitting your time working on a program in two parts: designing a piece of code with paper and pencil and, once thought through, encoding, testing and debugging. Try this on a day to day basis and you will after a couple of weeks find out that you saved a lot of work by reducing trial and error (a good programmer is said to write on annual average five lines of code per day).


Meta books:

Diese Bücher sind kein direktes Muss für das Verfassen der Arbeit, dienen aber den berühmten "Soft-skills". Eine Investition an dieser Stelle zahlt sich mit Sicherheit aus.

Zeitmanagement

Seiwert, L. (1998). Wenn Du es eilig hast, gehe langsam. Campus Fachbuch.

Studieren

Knigge-Illner, H., und Kruse, O. (1994). Studieren mit Lust und Methode. Deutscher Studienverlag.

Schreiben

Kruse, O. (1999). Keine Angst vor dem leeren Blatt. campus concret.

Rhetorik

Kellner, H. (2000). Rhetorik. Hanser Verlag.


Related sites:

These sites may be of additonal help to you:
  • More texts on how to write can be found at CMU.
  • and at Student Support.
  • A number of mailing lists for artificial intelligence can be found at UMBC.
  • Your work will usually include some program writing. If you always wanted to know how to drive all future users of your code to madness: well, check this.
  • For tips on more advanced projects (PhD etc.), see A. Bundy's page, Toby Walsh's page or the page of Sylvia Miksch.

A last word before you go (Edsger Dijkstra's tips for PhD students):
  • Never compete with colleagues
  • Try the most difficult thing you can do
  • Choose what is scientifically healthy and relevant. Don't compromise on scientific integrety.


Many thanks go to Chris Kray, Andreas Gerber, Alastair Burt and Hans-Jürgen Bürckert for contributing a lot of tips to this page!

Last updated on February 15, 2003.

If you know of some more tips, please contact schillo@virtosphere.de