Commit 9de80002 authored by Valentin Bruch's avatar Valentin Bruch

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

parents 3fe0e5d5 89317d93
......@@ -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}
......@@ -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}
......@@ -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}
......@@ -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}
......@@ -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}
......@@ -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}
......@@ -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}
......@@ -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}
......@@ -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}
......
......@@ -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+"{}+
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment