Lecture at IDE Autumn School 2018

I had the great pleasure to give two lectures at the IDE Autumn School 2018 „Digitale Edition – Vertiefung und Nutzung“. The autumn school joins scholars from all areas of the Digital Humanities and aims at broadening their toolsets (see the remarkable syllabus of this year's school).

My task was to talk about network analysis, including graph-theoretic centrality measures and graph visualization in Python. I chose Shakespeare's Hamlet as a toy example, making use of the CSV-files from Roger W. Haworth. The slightly edited CSV-file and the Jupyter Notebooks (handout and solution) are available for download. And so are, of course, the slides (just click on the image below).

My First Lecture in Numbers

It's done! The semester is over and I graded the last student of my lecture "Information-Theoretic System Analysis and Design". It was a great experience, and I thank Gerhard Kramer for offering me this opportunity. I also owe Lars, my colleage, more than a few drinks for taking care of most of the problem classes, and my colleagues Andrei and Ali for interesting discussions and comments about the course material. And I also thank my students, who bore with me until the end of the semester, and who were never tired of asking interesting questions -- I think I've never had such an engaged, excited audience.

Here's the course in numbers:

• (I think) I held 14 lectures. Lars and I shared 6 problem classes.
• I spend roughly 200 hours preparing course notes, lecturing, correcting deliverables, etc.
• In the problem classes, students calculated 11 problems in front of their peers. The remaining 7 problems were done by Lars.
• We had 1 exam and 2 mandatory homework assignments, weighed 50%-25%-25%.
• Both homeworks had 9 problems.
• We had 8 regular students with (as far as I know) 8 different nationalities, originating from 2 continents.
• 7 of these students took the exam and delivered the 2 homework exercises. The average grade of this course was 1.35.
• The course notes totaled to 102 pages, containing 8 chapters, 40 worked examples, and 62 end-of-chapter problems.
• 6 students finished the course evaluation. An excerpt is shown below.

Course Evaluation (in parts)

And here are some lessons I learned:

• My PhD thesis is far from complete.
• There is never enough time to prepare course notes. Even though the course was based on my PhD thesis, it was hard work to prepare the results in an understandable manner.
• You have to make sure that the description of homework problems is precise and complete.
• Don't get confused by registration numbers. 30+ students registered for the course, but in the first lecture less than 10 showed up. Apparently (so I was told), many students register for a course to get the course notes on Moodle.
• Students prefer a script that they can get printed at the Fachschaft. Putting chapters online a few days before the lecture is ok, but a script is better.
• It's good not to have a sttrict course syllabus if's the first time you give the course. You never how exactly how much time you have to spend at a given topic, so it's better to leave room for changes. Still, it's a good idea to have at least a rough sketch of what topics you want to cover.

Writing for Wikipedia: Results of a Teaching Experiment

Some time ago I wrote an entry on a teaching experiment I wanted to conduct at TUM: As part of their graduate seminar, students have to get familiar with a scientific topic, present its core aspects in front of their peers, and write a LaTeX article summarizing again the main points. To get truly sustainable results, I asked the students to prepare their articles as if they wrote for Wikipedia. In other words, the target audience is the interested layperson, and while one should not shy away from presenting math, it should be accompanied by motivating examples and easy explanation.

And here are the results of this teaching experiment:

• Of the eight topics we offered, seven were taking, of which four were particularly suitable to become a Wikipedia article; two more could at least be added as subsections.
• Three of the suitable topics were very well prepared; so well, that we immediately recommended uploading them to Wikipedia.
• Since uploading was voluntary, only two of these three articles now appear on Wikipedia: An article on SUDOKU codes and another one on Information Dimension.
• The official course evaluation (six students participated), asking roughly 20 Likert-type questions, revealed that the course scored better than the department average over all graduate seminars (with one exception: students mentioned that there was not enough time to fulfill all tasks).
• Students also seemed to like the Wikipedia experiment: In an unofficial course evaluation, I asked eight Likert-type questions (5 = fully agree, 1 = do not agree at all; 7 students participated). The results showed that students found writing for Wikipedia motivating (average score: 4.29), that they liked writing the article first in LaTeX (5), that they would not really want to write it directly in Wikipedia (2.29), and that they learned a lot about both scientific writing and LaTeX (4.43 each). They did not learn too much about writing for Wikipedia, though (3.93).

Not sure if this qualifies as a successful teaching experiment or not - in any case, there are several things I took away from conducting the experiment:

• If you tell students to write for Wikipedia, tell them how to do it! We had a short lecture on scientific writing, but for the present case this should have been complemented by a 30 minute talk on how to write for Wikipedia.
• If you tell students to write for Wikipedia, make sure the topics are all suitable: What if a student does a very good job on a ridiculously narrow topic that can never make it into a Wikipedia article?
• Students need time. Five weeks are not enough to get familiar with a topic and prepare a well-written summary. Students should also be allowed to work on that during their winter break (that doesn't mean that they should do it - but they should be able to choose).
• During the preparation for the course, I found that there is actually more difference between a Wikipedia article and a scientific manuscript than I expected: Not only is the IMRAD structure not applicable, there is not abstract either, and also the writing style is entirely different: While in scientific manuscripts we try to write lively by including "we" as often as possible, a "we" would appear out of place in a Wikipedia article. The most challenging part, however, is the lead section: These few sentences right after the heading should deliver all relevant information of the article - "For many, it may be the only section that they read. A good lead section cultivates the reader's interest in reading more of the article, but not by teasing the reader or hinting at content that follows." Living up to these expectations is often too hard for scientists (it is for me), so how can we expect it from students?

Concluding, I hope I can repeat that experiment at a later time. Next time, three Wikipedia articles should be the absolute minimum!

Writing for Wikipedia: A Teaching Experiment

Writing reports and presenting results is an important part in an engineer's life, hence teaching these skills is an important (implicit or explicit) part in engineering curricula. At my former affiliation, SPSC at Graz University of Technology, we were teaching the course "Verfassen wissenschaftlicher Arbeiten" to bachelor's students in their fifth semester, preparing them for the challenging task of writing and presenting their bachelor's thesis. There, the approach was (roughly) as follows:

• Students grouped in pairs or triples and chose a topic related to the scientific process (e.g., writing good introductions, writing abstracts, giving a scientific presentation, plagiarism and literature searches, etc.).
• They had to give a presentation on this topic, teaching their colleagues the respective skills (flipped classroom).
• They chose a simple topic from signal processing (e.g., filter design) and wrote a four-page scientific LaTeX article presenting the topic as if it was their own invention.

Let me stress that again: Students should not write a review or a summary, but a scientific paper with a "novel" contribution. Why? Because that's what they have to do when they stay in academia.

Here, at the LNT of Technische Universitaet Muenchen, the offered Gradiate Seminar Mobile Communications and Coding is a very similar course (albeit for master's students): The expected outcomes are again presentation and writing skills, together with acquiring knowledge in a particular field inside communications and coding. In the last years, the approach was as follows:

• Each student chose a scientific topic and had to write a four-page scientific LaTeX article summarizing the core aspects (in the structure of a scientific paper).
• Students had to present these core aspects in a 20 minutes presentation.

The difference is apparent: Students at LNT had to write and present summaries rather than writing papers claiming original contribution. Why? Probably because that's what they have to do when they will NOT stay in academia.

But both approaches have one thing in common: Guess what happens to these four-page articles the students write. Nothing. I strongly doubt that any of our students every took a look at their paper after the end of the course. That does not mean that these articles are useless. They are not only formal requirements to achieve the degree, but they are valuable stepping stones for acquiring important skills: writing scientifically, learning about communications or signal processing, etc. In other words, the student must so to speak throw away the ladder, after he has climbed up on it.

In an effort to reduce the number of ladders thrown away, my colleague last semester required the students to copy their articles into a wiki accessible only for registered members. This was an amazing idea, one that made the seminar much more sustainable than it was before, and browsing through last year's student wiki articles gave me a good idea about what the students are capable of. Nevertheless, while the ladders are not thrown away now, they are still neatly locked up in a room in the basement.

This winter term, in which I am co-responsible for the course, I'd like to go one step further: Of all the ladders the students climb in this term, together with my colleagues we will select the most useful ones and try to make them fit for others to climb: The best student articles should end up as articles on Wikipedia. The idea is not new, as there have been several studies investigating the success of this method (for example, this one; for the supplementary material you need a subscription).

I'm not sure if we will succeed in this. Honestly, I would not want to write a Wikipedia article. But of the eight topics we are going to provide, at least four will be appropriate for an article, and at least two others could extend existing articles. Just to give you an example: As of Septemer 23rd, 2015, there is no Wikipedia article on information dimension. If such an article appears in Wikipedia by the end of January 2016, then the teaching experiment will have been successful. I'll keep you posted!

Convolution with Deltas - A Word on Notation

Mathematical notation is important. This is true even more so if we consider the convolution between two functions or between two sequences. In particular, if $f$ and $g$ are two functions, we write for the convolution

$$ h(x) = (f * g)(x) $$

whereas if $\{a_n\}$ and $\{b_n\}$ are two sequences, the convolution can be written as

$$ {c[n]} = {a[n]}*{b[n]}. $$

What should not be done in any circumstance is to write the convolution of two functions as

$$ h(t) = f(t) * g(t). $$

Why not? Well, because the convolution operator $*$ does not operate on value but on functions; $f(t)$ and $g(t)$, however, are values. That can be easily seen by inserting $t=3$ in above equation. We get

$$ h(3) = f(e) * g(3) $$

which obviously does not make any sense. The equation

$$ h(3) = (f*g)(3) $$

is the only appropriate way of writing this. In stark contrast, take a different unitary operator, like addition. For addition one can easily argue that the value of the sum of two functions at a given point equals the sum of the values of the individual functions: Addition works on values, i.e.,

$$ h(t) = (f+g)(t) = f(t)+g(t). $$

Still, many excellent textbooks on signal processing (even the ones from Oppenheim and Schafer and from Vetterli) make use of this "abuse of notation" for convolution. The reason is that as soon a Dirac (or Kronecker) delta enters the game, the famous convolution property pops up somewhere. In incorrect notation, this property can be stated as follows:

$$ h(t)=f(t) * \delta(t-T) = f(t-T) $$

Finding a correct notation is not easy. I found a few helpful comments on stackexchange. I will add my idea at the bottom, please judge yourself which you like the most. I have to admit that actually none of these is really satisfactory...

1. One commenter suggested to introduce the shift operator $T_T$, i.e., $T_T$ is the function mapping $t$ to $t-T$. Then, $\delta(t-T)=\delta(T_T(t))=(\delta\circ T_T)(t)$ and we get $h(t)=(f*(\delta\circ T_T))(t)$.
2. Another commenter proposed to write $h(t) = (f*\delta(\cdot-T))(t)$.
3. My idea is to define an ensemble of functions $\delta_T(t):=\delta(t−T)$ and then write the convolution as $h(t)=(f*\delta_T)(t)$.

While my comment might give the shortest notation, it is not as general as the one with the shift operator. I would have problems, e.g., to write the convolution of a function with its time-reversal, i.e., (in bad notation), $h(t)=f(t)*f(-t)$. If we introduce a time-reversal operator $R$ for which $R(t)=-t$, we could write the convolution easily as $h(t)=(f*f\circ R)(t)$.