Troels Henriksens academic homepage

A photograph of Troels Henriksen.

Synopsis

I am employed as tenure-track assistant professor at DIKU where I am part of the PLTC section. My research concerns parallel functional programming, high performance computing, and compiler construction.

I am currently teaching the following courses:

My personal homepage is sigkill.dk (or troelshenriksen.dk). I can be contacted at athas@sigkill.dk or athas@di.ku.dk.

My Google Scholar profile probably lists all of my academic publications.

How to find me

My office is on Earth, Denmark, Copenhagen, Universitetsparken 5 (the HCØ Institute), room 772-01-0-S14. The last step is the most tricky one. My office is located on the ground floor in the "B" building (the one closest to the white DIKU building). Follow the map below. You may find your way barred by a closed door. If you are a student, your card may be able to grant you access. Otherwise, ring the bell or call me. A map to my office.

Supervision

I am willing to supervise BSc and MSc projects that are related to my own research, or on topics that happen to catch my fancy. The projects tend to be heavy on implementation and somewhat technically difficult, but most of my former students claim to have enjoyed it.

When filling out projects contracts and such, use the following information:

How many hours are set aside for supervision?
In practice as many as necessary, but put 5 hours for a 7.5 ECTS project, 10 hours for a 15 ECTS project, and 20 hours for a 30 ECTS project.
How often do we meet for supervision?
Once per week, at a fixed time we agree upon after signing the contract. It is likely that many of the meetings will be cancelled when there is nothing to talk about, but having a regular slot avoids frequent calendar synchronisation.
What is expected of the student at the meeting?
The student must send an agenda or a cancellation at least the evening before the day of the meeting.
What is expected of the supervisor at the meeting?
The supervisor should have pondered any questions asked in the meeting agenda.

Signature

UCPH has an interesting procedure where I have to pretend to sign your contract by copying an image of my signature into your PDF file. As an optimisation, here is an image of my signature so you can do it yourself: If you wish to see me operate a fountain pen in person, you can also come by my office with a printout of your contract.

Project proposals

The following is a (mostly historical) archive of various project proposals. The recent ones may still be current. If you are a student, and looking for a project, you can check these out to get an idea of the kinds of projects I supervise.

As examples of prior work, see this collection of Futhark-related student projects. Not all of these were supervised by me.

Hints for doing a student project with me

For electronic communication, use email. I prefer athas@sigkill.dk for various reasons. Rationale: This saves me from having to search a multitude of communication mediums whenever I need to figure out the context of our conversation. As a special case, feel free to contact me on IRC, because IRC is a pleasant medium.

If your project involves modifying a program maintained in a Git repository (such as Futhark), use a feature branch for your project and issue a pull request against the main repository. Rationale: Using a distinct branch names makes it much easier for me to help you by checking out your code as a local branch, and issuing a pull request enables use of GitHub's tools for code review.

Feel free to write me emails with questions whenever you have any. I will respond as I am able.

When you desire feedback on your report, tell me specifically which part you want me to read, especially when I have previously given you feedback.

Regarding the report

Read Writing for Computer Science. Most of my advice would just be less precise parts of what I remember from that book.

There are no formal requirements for length or formatting, but do exercise common sense. See this list of student projects for examples. A BSc thesis is often about 25 pages, and a MSc thesis about 50 pages, but the variance is large. Shorter is better.

Do not include your source code (if any) as an appendix to your report. You can attach it to your handin (please no tarbombs) if you wish, but referencing some public location, such as GitHub, is also perfectly acceptable.

If you wish, you can use this LaTeX template. Note that there are obsolete versions circulating (full of encoding errors), but the one linked above should work.

Regarding the defense

A bachelors project defense is about 20 minutes of presentation, followed by 20 minutes of the censor and I asking questions. A master's thesis is about 25 minutes of presentation and 25 minutes of questions. For a joint defense, each student beyond the first adds about 5 minutes.

Make sure to check in advance that your electronic equipment works. It is your reponsibility to bring whatever dongles you need.

Use black text on a white background for your slides. The lighting conditions are usually not good enough for white-on-black to be legible.

Beamer defaults to an aspect ratio of 4:3, which is obsolete even on UCPH's projectors. Use \documentclass[aspectratio=169]{beamer} to enable a modern 16:9 aspect ratio. There is a UCPH beamer template circulating. Do not use it! It is extremely ugly. Also, remember to disable the navigation buttons that Beamer also inexplicably places on slides: \usenavigationsymbolstemplate{}

Have your code (if applicable) and report at hand to show on the projector, in case we want to point to specific parts in our questions.

Feel free to invite friends, family, lovers, enemies, colleagues, or anyone else you wish to your defense, but let me know well in advance so I can book a room with sufficient capacity.

The purpose of the defense is to evaluate your dissemination skills. The presentation part is slightly artificial, as both censor and I will have read your report in advance, so you do not have to exhaustively describe the background, context, or every technical detail. My advice is to superficially cover every main aspect of your work, then pick a single technical detail that you can discuss in depth.

We may ask questions about any part of your work, not just your presentation.

It is permissible to present new work at the defense. This can be anything from additional experimental data, to solving a problem that was unsolved at the report deadline.