Seminar Papers
Each seminar includes writing a paper of your topic.
Process
- You can start working on your paper before or after your presentation. The timing is up to you. The closer the preparation is to the presentation, the more present the content will be to you.
- Please, do not send in your submissions to individual team members (either
moodle or
db-lehre@cs.uni-tuebingen.de
) - Submission deadlines:
winter term summer term first version middle of February middle of August review beginning of March end of August final version middle of March middle of September - Please include paper, slides, and code (if applicable; preferably a GitHub link/invitation) in your final submission (unless moodle is used).
Form
- The paper of your programming topic must be written with LaTeX or Typst. For this purpose, the two-column SIGCONF Proceedings template must be used. These are the templates in LaTex and Typst.
- For figures, we recommend TikZ in LaTex, and fletcher and CeTZ in Typst.
- The paper should be 4-5 pages (bachelor) / 5-6 pages (master) in total and written in English.
- For linguistic correctness in English, we recommend using Grammarly, DeepL, or similar tools (not ChatGPT).
- You may borrow literature to improve your writing at our chair. Zobel, Justin: Writing for Computer Science
Content
- [for our programming seminars:] Your paper should include some form of discussion where you critically review your work in terms of
- performance analysis (O-notation). Please, do not include measurements on how long the programm ran on your personal laptop. These numbers don’t tell us anything.
- scalability. Does run time increase significantly when choosing larger inputs? When are space limitations met (e.g. stack overflow)?
- programming language. In hindsight, was the programming language appropriate for the problem? Which language properties were especially useful/difficult?
- your implementation. Are there aspects of the implementation you would do differently next time?
Evaluation Criteria
The following evaluation criteria will be applied to the papers:
- Form (typesetting, illustrations, formatting)
- Language (grammar, comprehensibility)
- Presentation of the own solution (intelligibility, correctness, comprehensibility, critical view)
As a rule, the paper makes up 50% of the final grade.
Examples of past, (very) good seminar papers
- Befunge-93 in SQL (Tim Fischer) [SQL is a Programming Language]
- Distance-Vector Routing With SQL (Alexej Onken) [SQL is a Programming Language]
Common pitfalls
we often find student papers to … | please, instead … |
---|---|
❌ be incomplete in terms of content | ✅ abstract, introduction, discussion (critical view) and conclusion are also inherent parts of a paper. |
❌ have frequent orthographic and grammatical errors | ✅ use Grammarly, DeepL or similar tools. |
❌ have punctuation errors | ✅ use commas, hyphens, dashes, semicolons, and colons correctly (different from German). |
❌ use passive voice extensively | ✅ use active voice as often as possible: “I/we analyse/implement/investigate” is perfectly fine. |
❌ use complicated sentences that (are supposed to) sound intelligent | ✅ KISS is as important for writing as for programming. |
❌ have a wall of text or one sentence paragraphs/sections | ✅ choose appropriate paragraph lengths. |
❌ show off the author’s intellect by using phrases like “obviously”, “very easy”, “as we all know” | ✅ stay objective. At best, something is “well-known” or “straightforward”. |
❌ misuse ie, i. e., “… mammals e.g. elephants, …” | ✅ know your latin and use appropriate punctuation. |
❌ use numbers incorrectly: “there are 3 different …” | ✅ spell out numbers 1-10. When to spell out numbers. |
❌ use several synonyms to vary expressions and avoid repitition | ✅ stick to one word/phrase for a concept, no need to confuse the reader. |
❌ lessen the strength of your statements by using filling words etc. | ✅ be clear (even if it feels bold). |
❌ contain errors like “in figure 3…”, “in the upcoming Section…” | ✅ capitaize if a figure, table, section,… is referenced by number. If not, don’t. |
Additionally,
- listings: Provide a caption (below), reference it in the text, provide line numbering, use syntax highlighting and a typewriter-style font.
- figures: Provide a caption (below), reference it in the text, pay attention to similar spacing above and below the figure.
- tables: Provide a caption (above!), reference it in the text, use booktabs style.