Merge branch 'master' of git.fsmpi.rwth-aachen.de:osak/talks

workshops/latex/beispieldokument/zeta_0.tex

@@ -40,21 +40,30 @@ Na klar.
 Im vorigen Unterabschnitt haben wir bemerkt, dass wir die Summe auffassen 
 können als einen Grenzwert der Zetafunktion.
 
-Epilog
-
-Dieser Teil soll nachher nicht im Inhaltsverzeichnis auftauchen, und 
-erhält damit auch keine Nummer. \\
-Außerdem:
-
-· Strukturierte Dokumente sind einfach mit \LaTeX.
-
-· Makros machen einem das Leben leicht.
-
-· Formeln -- und auch der ganze Rest -- sehen (noch nicht) toll aus.
-
-· Referenzen auf alles mögliche, also (Unter)abschnitte,
-    Gleichungen, Abbildungen, Tabellen, ... sind automatisch richtig.
-
-· Eigentlich ist das alles gar nicht so schwierig.
+Epilog -- Ein paar Programmiertipps von Rob Pike
+
+Most programs are too complicated - that is, more complex than they
+need to be to solve their problems efficiently.  Why? Mostly
+it's because of bad design, but I will skip that issue here because
+it's a big one.  But programs are often complicated at the
+microscopic level, and that is something I can address here.
+
+You can't tell where a program is going to spend its
+    time. Bottlenecks occur in surprising places, so don't try to second
+    guess and put in a speed hack until you've proven that's where the
+    bottleneck is.
+
+Measure. Don't tune for speed until you've measured,
+    and even then don't unless one part of the code overwhelms the rest.
+
+Fancy algorithms are slow when n is small, and n
+    is usually small. Fancy algorithms have big constants. Until you know that
+    n is frequently going to be big, don't get fancy.  (Even if n does get
+    big, use 2. first.) For example, binary trees are always faster
+    than splay trees for workaday problems.
+
+Fancy algorithms are buggier than simple ones, and
+    they're much harder to implement.  Use simple algorithms as well as simple
+    data structures.
 
 \end{document}

workshops/latex/beispieldokument/zeta_1.tex

@@ -42,21 +42,30 @@ Na klar.
 Im vorigen Unterabschnitt haben wir bemerkt, dass wir die Summe auffassen 
 können als einen Grenzwert der Zetafunktion.
 
-Epilog
-
-Dieser Teil soll nachher \textcolor{red}{nicht} im Inhaltsverzeichnis auftauchen, und 
-erhält damit auch keine Nummer. \\
-Außerdem:
-
-· Strukturierte Dokumente sind einfach mit \LaTeX.
-
-· Makros machen einem das Leben leicht.
-
-· Formeln -- und auch der ganze Rest -- sehen (noch nicht) toll aus.
-
-· Referenzen auf alles mögliche, also (Unter)abschnitte,
-    Gleichungen, Abbildungen, Tabellen, ... sind automatisch richtig.
-
-· Eigentlich ist das alles gar nicht so schwierig.
+Epilog -- Ein paar Programmiertipps von Rob Pike
+
+Most programs are too \textbf{complicated} - that is, more complex than they
+\textit{need} to be to solve their problems \textit{efficiently}.  Why? Mostly
+it's because of \textbf{bad design}, but I will skip that issue here because
+it's a \textbf{\textcolor{red}{big}} one.  But programs are often complicated at the
+microscopic level, and that is something I can address here.
+
+\textcolor{red}{You can't tell where a program is going to spend its
+    time.}  Bottlenecks occur in surprising places, so don't try to second
+    guess and put in a speed hack until you've proven that's where the
+    bottleneck is.
+
+\textcolor{red}{Measure.} Don't tune for speed until you've measured,
+    and even then don't unless one part of the code overwhelms the rest.
+
+\textcolor{red}{Fancy algorithms are slow when n is small}, and n
+    is usually small. Fancy algorithms have big constants. Until you know that
+    n is frequently going to be big, don't get fancy.  (Even if n does get
+    big, use 2. first.) For example, binary trees are always faster
+    than splay trees for workaday problems.
+
+\textcolor{red}{Fancy algorithms are buggier} than simple ones, and
+    they're much harder to implement.  Use simple algorithms as well as simple
+    data structures.
 
 \end{document}

workshops/latex/beispieldokument/zeta_2.tex

@@ -44,21 +44,29 @@ Ergebnis führt.
 Im vorigen Unterabschnitt haben wir bemerkt, dass wir die Summe auffassen 
 können als einen Grenzwert der Zetafunktion.
 
-\section*{Epilog}
-
-Dieser Teil soll nachher \textcolor{red}{nicht} im Inhaltsverzeichnis auftauchen, und 
-erhält damit auch keine Nummer. \\
-Außerdem:
-
-· Strukturierte Dokumente sind einfach mit \LaTeX.
-
-· Makros machen einem das Leben leicht.
-
-· Formeln -- und auch der ganze Rest -- sehen (noch nicht) toll aus.
-
-· Referenzen auf alles mögliche, also (Unter)abschnitte,
-    Gleichungen, Abbildungen, Tabellen, ... sind automatisch richtig.
-
-· Eigentlich ist das alles gar nicht so schwierig.
+\section*{Epilog -- Ein paar Programmiertipps von Rob Pike}
+Most programs are too \textbf{complicated} - that is, more complex than they
+\textit{need} to be to solve their problems \textit{efficiently}.  Why? Mostly
+it's because of \textbf{bad design}, but I will skip that issue here because
+it's a \textbf{\textcolor{red}{big}} one.  But programs are often complicated at the
+microscopic level, and that is something I can address here.
+
+\textcolor{red}{You can't tell where a program is going to spend its
+    time.}  Bottlenecks occur in surprising places, so don't try to second
+    guess and put in a speed hack until you've proven that's where the
+    bottleneck is.
+
+\textcolor{red}{Measure.} Don't tune for speed until you've measured,
+    and even then don't unless one part of the code overwhelms the rest.
+
+\textcolor{red}{Fancy algorithms are slow when n is small}, and n
+    is usually small. Fancy algorithms have big constants. Until you know that
+    n is frequently going to be big, don't get fancy.  (Even if n does get
+    big, use 2. first.) For example, binary trees are always faster
+    than splay trees for workaday problems.
+
+\textcolor{red}{Fancy algorithms are buggier} than simple ones, and
+    they're much harder to implement.  Use simple algorithms as well as simple
+    data structures.
 
 \end{document}

workshops/latex/beispieldokument/zeta_3.tex

@@ -46,19 +46,27 @@ Ergebnis führt.
 Im vorigen Unterabschnitt haben wir bemerkt, dass wir die Summe auffassen 
 können als einen Grenzwert der Zetafunktion.
 
-\section*{Epilog}
-
-Dieser Teil soll nachher \textcolor{red}{nicht} im Inhaltsverzeichnis auftauchen, und 
-erhält damit auch keine Nummer. \\
-Außerdem:
-
-\begin{itemize}
-  \item Strukturierte Dokumente sind einfach mit \LaTeX.
-  \item Makros machen einem das Leben leicht.
-  \item Formeln -- und auch der ganze Rest -- sehen (noch nicht) toll aus.
-  \item Referenzen auf alles mögliche, also (Unter)abschnitte,
-    Gleichungen, Abbildungen, Tabellen, ... sind automatisch richtig.
-  \item Eigentlich ist das alles gar nicht so schwierig.
-\end{itemize}
+\section*{Epilog -- Ein paar Programmiertipps von Rob Pike}
+Most programs are too \textbf{complicated} - that is, more complex than they
+\textit{need} to be to solve their problems \textit{efficiently}.  Why? Mostly
+it's because of \textbf{bad design}, but I will skip that issue here because
+it's a \textbf{\textcolor{red}{big}} one.  But programs are often complicated at the
+microscopic level, and that is something I can address here.
+\begin{enumerate}
+  \item  \textcolor{red}{You can't tell where a program is going to spend its
+    time.}  Bottlenecks occur in surprising places, so don't try to second
+    guess and put in a speed hack until you've proven that's where the
+    bottleneck is.
+  \item  \textcolor{red}{Measure.} Don't tune for speed until you've measured,
+    and even then don't unless one part of the code overwhelms the rest.
+  \item  \textcolor{red}{Fancy algorithms are slow when n is small}, and n
+    is usually small. Fancy algorithms have big constants. Until you know that
+    n is frequently going to be big, don't get fancy.  (Even if n does get
+    big, use 2. first.) For example, binary trees are always faster
+    than splay trees for workaday problems.
+  \item  \textcolor{red}{Fancy algorithms are buggier} than simple ones, and
+    they're much harder to implement.  Use simple algorithms as well as simple
+    data structures.
+\end{enumerate}
 
 \end{document}

workshops/latex/beispieldokument/zeta_4.tex

@@ -49,19 +49,27 @@ Ergebnis führt.
 Im vorigen Unterabschnitt haben wir bemerkt, dass wir die Summe auffassen 
 können als einen Grenzwert der Zetafunktion, $\zeta(-1) = -1/12$.
 
-\section*{Epilog}
-
-Dieser Teil soll nachher \textcolor{red}{nicht} im Inhaltsverzeichnis auftauchen, und 
-erhält damit auch keine Nummer. \\
-Außerdem:
-
-\begin{itemize}
-  \item Strukturierte Dokumente sind einfach mit \LaTeX.
-  \item Makros machen einem das Leben leicht.
-  \item Formeln -- und auch der ganze Rest -- sehen (noch nicht) toll aus.
-  \item Referenzen auf alles mögliche, also (Unter)$^n$abschnitte,
-    Gleichungen, Abbildungen, Tabellen, ... sind automatisch richtig.
-  \item Eigentlich ist das alles gar nicht so schwierig.
-\end{itemize}
+\section*{Epilog -- Ein paar Programmiertipps von Rob Pike}
+Most programs are too \textbf{complicated} - that is, more complex than they
+\textit{need} to be to solve their problems \textit{efficiently}.  Why? Mostly
+it's because of \textbf{bad design}, but I will skip that issue here because
+it's a \textbf{\textcolor{red}{big}} one.  But programs are often complicated at the
+microscopic level, and that is something I can address here.
+\begin{enumerate}
+  \item  \textcolor{red}{You can't tell where a program is going to spend its
+    time.}  Bottlenecks occur in surprising places, so don't try to second
+    guess and put in a speed hack until you've proven that's where the
+    bottleneck is.
+  \item  \textcolor{red}{Measure.} Don't tune for speed until you've measured,
+    and even then don't unless one part of the code overwhelms the rest.
+  \item  \textcolor{red}{Fancy algorithms are slow when $n$ is small}, and $n$
+    is usually small. Fancy algorithms have big constants. Until you know that
+    $n$ is frequently going to be big, don't get fancy.  (Even if $n$ does get
+    big, use 2. first.) For example, binary trees are always faster
+    than splay trees for workaday problems.
+  \item  \textcolor{red}{Fancy algorithms are buggier} than simple ones, and
+    they're much harder to implement.  Use simple algorithms as well as simple
+    data structures.
+\end{enumerate}
 
 \end{document}

workshops/latex/beispieldokument/zeta_5.tex

@@ -68,29 +68,30 @@ Tabelle 1: Wert der $n$-ten Partialsumme
   \end{tabular}
 \end{center}
 
-\section*{Epilog}
-
-Dieser Teil soll nachher \textcolor{red}{nicht} im Inhaltsverzeichnis auftauchen, und 
-erhält damit auch keine Nummer. \\
-Außerdem:
-
-\begin{itemize}
-  \item Strukturierte Dokumente sind einfach mit \LaTeX.
-  \item Makros machen einem das Leben leicht.
-  \item Formeln -- und auch der ganze Rest -- sehen (noch nicht) toll aus.
-  \item Referenzen auf alles mögliche, also (Unter)$^n$abschnitte,
-    Gleichungen, Abbildungen, Tabellen, ... sind automatisch richtig.
-  \item Eigentlich ist das alles gar nicht so schwierig.
-\end{itemize}
-
-\vfill
-% Der Befehl vfill fügt einen vertikalen Abstand ein, der den übrigen Platz
-% ausfüllt
+\section*{Epilog -- Ein paar Programmiertipps von Rob Pike}
+Most programs are too \textbf{complicated} - that is, more complex than they
+\textit{need} to be to solve their problems \textit{efficiently}.  Why? Mostly
+it's because of \textbf{bad design}, but I will skip that issue here because
+it's a \textbf{\textcolor{red}{big}} one.  But programs are often complicated at the
+microscopic level, and that is something I can address here.
+\begin{enumerate}
+  \item  \textcolor{red}{You can't tell where a program is going to spend its
+    time.}  Bottlenecks occur in surprising places, so don't try to second
+    guess and put in a speed hack until you've proven that's where the
+    bottleneck is.
+  \item  \textcolor{red}{Measure.} Don't tune for speed until you've measured,
+    and even then don't unless one part of the code overwhelms the rest.
+  \item  \textcolor{red}{Fancy algorithms are slow when $n$ is small}, and $n$
+    is usually small. Fancy algorithms have big constants. Until you know that
+    $n$ is frequently going to be big, don't get fancy.  (Even if $n$ does get
+    big, use 2. first.) For example, binary trees are always faster
+    than splay trees for workaday problems.
+  \item  \textcolor{red}{Fancy algorithms are buggier} than simple ones, and
+    they're much harder to implement.  Use simple algorithms as well as simple
+    data structures.
+\end{enumerate}
 \begin{center}
 \includegraphics[width=0.5\textwidth]{ctanlion.eps}
 \end{center}
-\vfill
-% die beiden Abstände werden gleichmäßig verteilt. Das Bild erscheint also in
-% der Mitte.
 
 \end{document}

workshops/latex/beispieldokument/zeta_6.tex

@@ -69,29 +69,30 @@ können als einen Grenzwert der Zetafunktion, $\zeta(-1) = -1/12$.
   \end{center}
 \end{table}
 
-\section*{Epilog}
-
-Dieser Teil soll nachher \textcolor{red}{nicht} im Inhaltsverzeichnis auftauchen, und 
-erhält damit auch keine Nummer. \\
-Außerdem:
-
-\begin{itemize}
-  \item Strukturierte Dokumente sind einfach mit \LaTeX.
-  \item Makros machen einem das Leben leicht.
-  \item Formeln -- und auch der ganze Rest -- sehen (noch nicht) toll aus.
-  \item Referenzen auf alles mögliche, also (Unter)$^n$abschnitte,
-    Gleichungen, Abbildungen, Tabellen, ... sind automatisch richtig.
-  \item Eigentlich ist das alles gar nicht so schwierig.
-\end{itemize}
-
-\vfill
-% Der Befehl vfill fügt einen vertikalen Abstand ein, der den übrigen Platz
-% ausfüllt
+\section*{Epilog -- Ein paar Programmiertipps von Rob Pike}
+Most programs are too \textbf{complicated} - that is, more complex than they
+\textit{need} to be to solve their problems \textit{efficiently}.  Why? Mostly
+it's because of \textbf{bad design}, but I will skip that issue here because
+it's a \textbf{\textcolor{red}{big}} one.  But programs are often complicated at the
+microscopic level, and that is something I can address here.
+\begin{enumerate}
+  \item  \textcolor{red}{You can't tell where a program is going to spend its
+    time.}  Bottlenecks occur in surprising places, so don't try to second
+    guess and put in a speed hack until you've proven that's where the
+    bottleneck is.
+  \item  \textcolor{red}{Measure.} Don't tune for speed until you've measured,
+    and even then don't unless one part of the code overwhelms the rest.
+  \item  \textcolor{red}{Fancy algorithms are slow when $n$ is small}, and $n$
+    is usually small. Fancy algorithms have big constants. Until you know that
+    $n$ is frequently going to be big, don't get fancy.  (Even if $n$ does get
+    big, use 2. first.) For example, binary trees are always faster
+    than splay trees for workaday problems.
+  \item  \textcolor{red}{Fancy algorithms are buggier} than simple ones, and
+    they're much harder to implement.  Use simple algorithms as well as simple
+    data structures.
+\end{enumerate}
 \begin{center}
 \includegraphics[width=0.5\textwidth]{ctanlion.eps}
 \end{center}
-\vfill
-% die beiden Abstände werden gleichmäßig verteilt. Das Bild erscheint also in
-% der Mitte.
 
 \end{document}

workshops/latex/beispieldokument/zeta_7.tex

@@ -72,29 +72,30 @@ können als einen Grenzwert der Zetafunktion, $\zeta(-1) = -1/12$.
   \end{center}
 \end{table}
 
-\section*{Epilog}
-
-Dieser Teil soll nachher \textcolor{red}{nicht} im Inhaltsverzeichnis auftauchen, und 
-erhält damit auch keine Nummer. \\
-Außerdem:
-
-\begin{itemize}
-  \item Strukturierte Dokumente sind einfach mit \LaTeX.
-  \item Makros machen einem das Leben leicht.
-  \item Formeln -- und auch der ganze Rest -- sehen (noch nicht) toll aus.
-  \item Referenzen auf alles mögliche, also (Unter)$^n$abschnitte,
-    Gleichungen, Abbildungen, Tabellen, ... sind automatisch richtig.
-  \item Eigentlich ist das alles gar nicht so schwierig.
-\end{itemize}
-
-\vfill
-% Der Befehl vfill fügt einen vertikalen Abstand ein, der den übrigen Platz
-% ausfüllt
+\section*{Epilog -- Ein paar Programmiertipps von Rob Pike}
+Most programs are too \textbf{complicated} - that is, more complex than they
+\textit{need} to be to solve their problems \textit{efficiently}.  Why? Mostly
+it's because of \textbf{bad design}, but I will skip that issue here because
+it's a \textbf{\textcolor{red}{big}} one.  But programs are often complicated at the
+microscopic level, and that is something I can address here.
+\begin{enumerate}
+  \item  \textcolor{red}{You can't tell where a program is going to spend its
+    time.}  Bottlenecks occur in surprising places, so don't try to second
+    guess and put in a speed hack until you've proven that's where the
+    bottleneck is.
+  \item  \label{measure}\textcolor{red}{Measure.} Don't tune for speed until you've measured,
+    and even then don't unless one part of the code overwhelms the rest.
+  \item  \textcolor{red}{Fancy algorithms are slow when $n$ is small}, and $n$
+    is usually small. Fancy algorithms have big constants. Until you know that
+    $n$ is frequently going to be big, don't get fancy.  (Even if $n$ does get
+    big, use \ref{measure}. first.) For example, binary trees are always faster
+    than splay trees for workaday problems.
+  \item  \textcolor{red}{Fancy algorithms are buggier} than simple ones, and
+    they're much harder to implement.  Use simple algorithms as well as simple
+    data structures.
+\end{enumerate}
 \begin{center}
 \includegraphics[width=0.5\textwidth]{ctanlion.eps}
 \end{center}
-\vfill
-% die beiden Abstände werden gleichmäßig verteilt. Das Bild erscheint also in
-% der Mitte.
 
 \end{document}

workshops/latex/beispieldokument/zeta_8.tex

@@ -71,24 +71,26 @@ können als einen Grenzwert der Zetafunktion, $\riemann$.
 \end{table}
 
 \section*{Epilog -- Ein paar Programmiertipps von Rob Pike}
-Most programs are too complicated - that is, more complex than they need to be
-to solve their problems efficiently.  Why? Mostly it's because of bad design,
-but I will skip that issue here because it's a big one.  But programs are often
-complicated at the microscopic level, and that is something I can address here.
+Most programs are too \textbf{complicated} - that is, more complex than they
+\textit{need} to be to solve their problems \textit{efficiently}.  Why? Mostly
+it's because of \textbf{bad design}, but I will skip that issue here because
+it's a \textbf{\textcolor{red}{big}} one.  But programs are often complicated at the
+microscopic level, and that is something I can address here.
 \begin{enumerate}
-  \item  You can't tell where a program is going to spend its
-      time.  Bottlenecks occur in surprising places, so don't try to second
-      guess and put in a speed hack until you've proven that's where the
-      bottleneck is.
-  \item  Measure.  Don't tune for speed until you've measured, and even then don't
-    unless one part of the code overwhelms the rest.
-  \item  Fancy algorithms are slow when $n$ is small, and $n$ is usually small.
-    Fancy algorithms have big constants. Until you know that $n$ is frequently
-    going to be big, don't get fancy.  (Even if $n$ does get big, use Rule 2
-    first.)   For example, binary trees are always faster than splay trees for
-    workaday problems.
-  \item  Fancy algorithms are buggier than simple ones, and they're much harder to
-    implement.  Use simple algorithms as well as simple data structures.
+  \item  \textcolor{red}{You can't tell where a program is going to spend its
+    time.}  Bottlenecks occur in surprising places, so don't try to second
+    guess and put in a speed hack until you've proven that's where the
+    bottleneck is.
+  \item  \label{measure}\textcolor{red}{Measure.} Don't tune for speed until you've measured,
+    and even then don't unless one part of the code overwhelms the rest.
+  \item  \textcolor{red}{Fancy algorithms are slow when $n$ is small}, and $n$
+    is usually small. Fancy algorithms have big constants. Until you know that
+    $n$ is frequently going to be big, don't get fancy.  (Even if $n$ does get
+    big, use \ref{measure}. first.) For example, binary trees are always faster
+    than splay trees for workaday problems.
+  \item  \textcolor{red}{Fancy algorithms are buggier} than simple ones, and
+    they're much harder to implement.  Use simple algorithms as well as simple
+    data structures.
 \end{enumerate}
 \begin{center}
 \includegraphics[width=0.5\textwidth]{ctanlion.eps}

workshops/latex/latex.tex

@@ -671,6 +671,7 @@
   \end{tikzpicture}
     \vspace{-6pt}
   \end{center}
+  \structure{URLs:} \highlightRed{\textbackslash url}\verb+{http://fsmpi.eu/latex}+ \\
   \structure{Besondere Zeichen}
   \begin{itemize}
     \item {\bfseries\color{MidnightBlue}\%, "{}}: \texttt{\textbackslash\%}, \verb+"{}+