Troels Henriksens academic homepage
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.
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.
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. Most of my projects are fairly well-defined regarding the eventual goal, but are open in terms of technique. Many of my projects are also directly related to either active open source projects, or ongoing research efforts.
When filling out projects contracts and such, use the following information:
You are also asked to write a project description, which contains a background and high level problem statement. You should write a first draft of this on your own, based on our discussions, as it is a useful test of how well you understand the goal of the project. One somewhat artificial part that the project description must contain is a list of 3-5 learning goals. These are actionable demonstrations of your (hopefully) newly acquired competences, and are to some extent what you will be evaluated on at the end of your project. Each learning goal is typically a single sentence. Here is an example of a project description.
Think about the goal of your project: Do you simply wish to try out interesting theory or technology? Contribute working code to an open source project? Contribute to a research project? Get a high grade as easily as possible? Make your goal clear to me so we both know what to aim for.
Valkyrie Savage has also written a helpful guide on being a project student.
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.
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.
The Problem Based Benchmark Suite is a collection of benchmark programs written in parallel C++. I am interested in porting them to Futhark such that they can be added to the existing collection of benchmarks. Some of the benchmarks are relatively trivial; others are more difficult. It might be a good idea for a project to combine a trivial benchmark with a more complex one. The list of benchmarks is here. The ones listed as Basic Building Blocks are all pretty straightforward, but not large enough to serve as a project on their own. Look at the others and pick whatever looks interesting. Particularly interesting are the ones related to computational geometry:
This project involves becoming familiar with data parallel programming and learning how to rephrase (typically) task parallel algorithms in the data parallel setting, usually also by flattening control flow and data.
The Futhark compiler currently supports regular nested data parallelism, which is a form of parallelism where the size of inner parallel dimensions are invariant to the outer dimensions. Even though we are working on supporting arbitrary irregular nested data parallelism, this will never be as efficient as regular nesting. Unfortunately, whether application parallelism is regular or irregular is an implicit property, and it can be hard for programmers to know when it occurs. This project is about writing a static analysis tool that takes as input a Futhark program and analyses it for potential instances of irregular nested data parallelism. This is a fun project if you enjoy working with ASTs and devising algorithms.
AD is a program transformation for computing derivatives of arbitrary programs. GradBench is a project that investigates the performance of AD tools for various languages. This project is about implementing one or more of the GradBench benchmarks in a new language or AD tool. For example, I am quite curious about the effectiveness of these AD tools for Haskell, but you can pick whatever language you wish, as long as it has some library or tool that supports AD. The concrete work done in the project is implementing the specified benchmark problems, applying AD as best you can, then benchmarking the resulting programs.
The Futhark compiler uses a traditional parser architecture, based on the Happy parser generator that stops at the first error and is unable to produce a parse tree in case a syntax error occurs. This means the compiler and related tools, such as the Language Server and formatter, is unable to provide any information when the program has a syntax error. This is not ideal, as it is common for programs to have intermittent syntax errors while working on them.
Happy recently grew support for error recovery, which has already been used to modify GHC. This project is about adding a similar form of error tolerance to the Futhark parser, and as time permits, investigating how to modify programs such as the type checker and formatter to handle incorrect programs. Although the Futhark compiler is written in Haskell, it is not expected that this project requires particularly fancy Haskell programming. It is a good project for students interested in parser theory and practice.
Futhark can produce a reasonable and ever-increasing amount of profiling information that describes which parts of a program execution are the most time consuming, and (to some extent), why. However, this information is currently not made available to the user in a particularly useful way. This project is about writing a program that takes the information that is being produced and presenting it in a more useful way. This can include:
The project is best implemented as an extension to the existing futhark profile tool, which is written in (rather simple) Haskell.
If successful, this project will be frequently used in practice by real Futhark programmers.
This section contains suggestions for where to go next if you liked a course that I have been involved with; particularly which other related courses would be worth taking, or who to contact to do a related BSc or MSc project. Use the Course Search to look up further details.
While I use a lot of the HPPS material in my own research, most of my projects also involve significant amounts of material related to functional programming, programming language theory, or compiler construction. For projects centered in the HPPS material, David Gray Marchant is a more suitable supervisor.
Many researchers at DIKU are willing to supervise projects related to functional programming or more generally the theory of programming. If you find monads or type systems particularly interesting, consider contacting Andrzej Filinski. Ken Friis Larsen is interested in most unusual uses of Haskell.
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 (#diku
on Libera Chat), 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.
You should generally think about what kind of help you need from me, and say so explicitly in your emails. I am often willing to put in significant amounts of work to help with technical obstacles that are peripheral to your project, but I am unlikely to take the initiative. I can also provide suggestions for alternative approaches when you are stuck, but I need to know when you get stuck.
Read Writing for Computer Science. Most of my advice would just be less precise parts of what I remember from that book. I also recommend reading How to Write a Great Research Paper, although it is primarily concerned with research papers.
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 if you wish (please no tarbombs), but referencing some public location, such as GitHub or Codeberg, 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.
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. A POCS with a single student does not have a defense.
There is no requirement to present using slides, but it by a significant margin the most common. Consider very carefully before deciding to do a presentation using only white- or blackboard.
There is no requirement for any specific presentation tool. Use something you are comfortable with. Most students use Beamer. Very cool students use Patat or write their own presentation software.
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.
If you wish to use Beamer, note that it 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 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 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.
For guidance on how to give a good presentation, see How to Give a Great Research Talk.
If you are dissatisfied with the grade you received at an exam, you can make a formal complaint. The outcome can be either a rejection of the complaint, offer of another exam attempt, or a re-assessment of the handin by another evaluator. The mechanics of complaining are documented officially elsewhere; the purpose of the following is to give you advice on writing a complaint that will work. I will be up front in admitting that my main objective is to reduce the number of exam complaints I have to process, by making students more aware of the reality of the process.
First, consider whether it is worth complaining. An exam complaint is a formal legal process that involves a lot of administrative personnel as well as the relevant teachers and censors, who have to write a precise response to the complaint, which is then evaluated by a study board. It is a serious process that emphasizes the rights of the student. It is however also a very time consuming process, and that is time that cannot then be spent on other job tasks, such as preparing teaching material. Even a spurious complaint will cause a lot of time to be spent, so consider carefully whether you think it is the best use of humanity's resources. And less altruistically, a complaint that is likely to be accepted will also require you to spend significant time. Perhaps this time is better spent on things that are more constructive. In general, I would advice not even considering complaining unless you absolutely need a higher grade (due to an exchange agreement or similar), and otherwise just accepting that the teacher is incompetent and/or a jerk and made a mistake when assessing your submission. It will not be the last time in your life that your merits are judged unfairly.
Before complaining, you should ask for feedback from the course responsible. Make sure to state your exam number. Perhaps you made mistakes you did not realise. The feedback you will receive is different from what you are used to, in that it is summative rather than formative - it justifies the grade, but is not intended to help you get better. You may even experience that the feedback is quite harsh and negatively slanted - this is not (necessarily) because the teacher dislikes you, but is a somewhat unfortunate consequence of the fact that exam complaints are so time-consuming to process. A teacher is incentivised to make sure that a student feels they deserve their grade, so that they are not tempted to write a complaint, which may otherwise be the case if the teacher mainly focuses on the positive aspects of an otherwise middle-of-the-road submission. Most teachers have been burnt in the past and so this can be seen as a trauma reaction. Some even refuse to give written feedback because they worry it will be used against them in a complaint (I am not yet one of these; feel free to ask for written feedback). This dystopian dynamic is one reason why exams are a somewhat miserable experience for all involved.
A common mistake is that students do not realise how they are assessed - specifically, you are graded entirely on your fulfilment of the learning goals, so if you happen to solve the exam problem in a "correct" way, but one that does not demonstrate mastery of the techniques specified in the course learning goals, then that is in principle worthless from a grading perspective. A common example for programming courses is to solve a problem in a way that does work, but does not use the approach you have been taught.
An complaint about an exam grade must take the form of explaining that the submission demonstrates mastery of the learning goals to a greater extent than reflected in the awarded grade. You should reference the specific learning goals of the course description, as well as the meaning of the grades according to the Danish grading system.
Another common misunderstanding is to assume that grading is perfectly consistent. It may well be that one of your peers handed in a solution of similar quality, and got a higher grade. This by itself is not grounds for a complaint - each submission is graded on its own. You cannot submit a complaint that one of your friends got an undeservedly high grade. Also, there is the phenomenon that the best submission to receive a grade of 7 is likely to be pretty close in quality to the worst submission to get a grade of 10. The unavoidable uncertainty in grading cannot be made the basis of an exam complaint.
If your complaint is rejected, it is possible to make an appeal. You should basically never do this. The appeals board takes an even more legalistic approach, and cares only about errors in the response to your complaint - they will not care about the details of the original assessment. You cannot contribute new information; it is not an opportunity for a do-over of your complaint. Only gross incompetence on behalf of the teacher and study board could possibly lead to a situation where an appeal is likely to be accepted.