Skip to content
GitLab
Menu
Projects
Groups
Snippets
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Sign in
Toggle navigation
Menu
Open sidebar
osak
talks
Commits
72cabc77
Commit
72cabc77
authored
Jun 02, 2019
by
Lennart Klebl
Browse files
beispieldokument, URLs in latex.tex
parent
54688c25
Changes
10
Hide whitespace changes
Inline
Side-by-side
workshops/latex/beispieldokument/zeta_0.tex
View file @
72cabc77
...
...
@@ -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
View file @
72cabc77
...
...
@@ -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
View file @
72cabc77
...
...
@@ -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
View file @
72cabc77
...
...
@@ -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
View file @
72cabc77
...
...
@@ -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
View file @
72cabc77
...
...
@@ -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
View file @
72cabc77
...
...
@@ -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
View file @
72cabc77
...
...
@@ -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
View file @
72cabc77
...
...
@@ -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
View file @
72cabc77
...
...
@@ -666,6 +666,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
+
"{}
+
...
...
Write
Preview
Supports
Markdown
0%
Try again
or
attach a new file
.
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment