teaching/scientificComputing
Archived
3
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

removed \codeterm (replaced by \entermde)

Browse Source
This commit is contained in:
Jan Benda 2019-12-10 09:14:10 +01:00
parent c063cc9f0e
commit 39a1e51bc4
4 changed files with 100 additions and 99 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

66
codestyle/lecture/codestyle.tex
View File

@ -33,7 +33,7 @@ by calling functions that work on the data and managing the
results. Applying this structure makes it easy to understand the flow
of the program but two questions remain: (i) How to organize the files
on the file system and (ii) how to name them that the controlling
script is easily identified among the other \codeterm[m-file]{m-files}.
script is easily identified among the other \entermde[m-file]{m-File}{m-files}.
Upon installation \matlab{} creates a folder called \file{MATLAB} in
the user space (Windows: My files, Linux: Documents, MacOS:
@ -43,7 +43,7 @@ moment. Of course, any other location can specified as well. Generally
it is of great advantage to store related scripts and functions within
the same folder on the hard drive. An easy approach is to create a
project-specific folder structure that contains sub-folders for each
task (analysis) and to store all related \codeterm[m-file]{m-files}
task (analysis) and to store all related \entermde[m-file]{m-File}{m-files}
(screenshot \ref{fileorganizationfig}). In these task-related folders
one may consider to create a further sub-folder to store results
(created figures, result data). On the project level a single script
@ -73,18 +73,18 @@ Box~\ref{matlabpathbox}).
\begin{ibox}[tp]{\label{matlabpathbox}\matlab{} search path}
The \codeterm{search path} defines where \matlab{} looks for scripts
and functions. When calling a function from the command line
\matlab{} needs to figure out which function is addressed and starts
looking for it in the current path. If this fails it will crawl all
locations listed in the search path (see figure). The
\codeterm{search path} is basically a list of folders. \matlab{}
will go through this list from front to end and the search will stop
on the first match. This implies that the order in the search path
may affect which version of functions that share the same name is
used. Note: \matlab{} does not perform a recursive search. That is,
a function that resides in a sub-folder that is not explicitly
listed in the \codeterm{search path} will not be found.
The \entermde{Suchpfad}{search path} defines where \matlab{} looks
for scripts and functions. When calling a function from the command
line \matlab{} needs to figure out which function is addressed and
starts looking for it in the current path. If this fails it will
crawl all locations listed in the search path (see figure). The
\entermde{Suchpfad}{search path} is basically a list of
folders. \matlab{} will go through this list from front to end and
the search will stop on the first match. This implies that the order
in the search path may affect which version of functions that share
the same name is used. Note: \matlab{} does not perform a recursive
search. That is, a function that resides in a sub-folder that is not
explicitly listed in the \entermde{Suchpfad}{search path} will not be found.
\vspace{2ex}
\includegraphics[width=0.9\textwidth]{search_path}
@ -307,7 +307,7 @@ and to briefly explain what they do. Whenever one feels tempted to do
this, one could also consider to delegate the respective task to a
function. In most cases this is preferable.
Not delegating the tasks leads to very long \codeterm[m-file]{m-files}
Not delegating the tasks leads to very long \entermde[m-file]{m-File}{m-files}
which can be confusing. Sometimes such a code is called ``spaghetti
code''. It is high time to think about delegation of tasks to
functions.
@ -323,9 +323,9 @@ functions.
\end{important}
\subsection{Local and nested functions}
Generally, functions live in their own \codeterm[m-file]{m-files} that
Generally, functions live in their own \entermde[m-file]{m-File}{m-files} that
have the same name as the function itself. Delegating tasks to
functions thus leads to a large set of \codeterm[m-file]{m-files}
functions thus leads to a large set of \entermde[m-file]{m-File}{m-files}
which increases complexity and may lead to confusion. If the delegated
functionality is used in multiple instances, it is still advisable to
do so. On the other hand, when the delegated functionality is only
@ -335,15 +335,17 @@ used within the context of another function \matlab{} allows to define
within the same file. Listing \ref{localfunctions} shows an example of
a local function definition.
\pagebreak[3] \lstinputlisting[label=localfunctions, caption={Example
for local functions.}]{calculateSines.m}
\pagebreak[3]
\lstinputlisting[label=localfunctions, caption={Example for local
functions.}]{calculateSines.m}
\emph{Local function} live in the same \codeterm{m-file} as the main
function and are only available in this context. Each local function
has its own \codeterm{scope}, that is, the local function can not
access (read or write) variables of the calling function. Interaction
with the local function requires to pass all required arguments and to
take care of the return values of the function.
\emph{Local function} live in the same \entermde{m-File}{m-file} as
the main function and are only available in this context. Each local
function has its own \enterm{scope}, that is, the local function can
not access (read or write) variables of the calling
function. Interaction with the local function requires to pass all
required arguments and to take care of the return values of the
function.
\emph{Nested functions} are different in this respect. They are
defined within the body of the parent function (between the keywords
@ -356,13 +358,13 @@ should take care when defining nested functions.
\section{Specifics when using scripts}
A similar problem as with nested function arises when using scripts
(instead of functions). All variables that are defined within a script
become available in the global \codeterm{workspace}. There is the risk
of name conflicts, that is, a called sub-script redefines or uses the
same variable name and may \emph{silently} change its content. The
user will not be notified about this change and the calling script may
expect a completely different content. Bugs that are based on such
mistakes are hard to find since the program itself looks perfectly
fine.
become available in the global \enterm{workspace}
(\determ{Arbeitsbereich}). There is the risk of name conflicts, that
is, a called sub-script redefines or uses the same variable name and
may \emph{silently} change its content. The user will not be notified
about this change and the calling script may expect a completely
different content. Bugs that are based on such mistakes are hard to
find since the program itself looks perfectly fine.
To avoid such issues one should design scripts in a way that they
perform their tasks independent from other scripts and functions.

5
header.tex
View File

@ -228,11 +228,6 @@
% the german index.
\newcommand{\determ}[2][]{``#2''\ifthenelse{\equal{#1}{}}{\protect\sindex[determ]{#2}}{\protect\sindex[determ]{#1}}}
% \codeterm[index entry]{<code>}
% typeset the term in italics and add it (or the optional argument) to
% the english and the german index.
\newcommand{\codeterm}[2][]{\textit{#2}\ifthenelse{\equal{#1}{}}{\protect\sindex[enterm]{#2}\protect\sindex[determ]{#2}}{\protect\sindex[enterm]{#1}\protect\sindex[determ]{#1}}}
\newcommand{\file}[1]{\texttt{#1}}
% for escaping special characters into the index:

20
plotting/lecture/plotting.tex
View File

@ -93,15 +93,15 @@ number of datasets.
\subsection{Simple plotting}
Creating a simple line-plot is rather easy. Assuming there exists a
variable \varcode{y} in the \codeterm{workspace} that contains the
measurement data it is enough to call \code[plot()]{plot(y)}. At the
first call of this function a new \codeterm{figure} will be opened and
the data will be plotted with as a line plot. If you repeatedly call
this function the current plot will be replaced unless the
\code[hold]{hold on} command was issued before. If it was, the current
plot is held and a second line will be added to it. Calling
\code[hold]{hold off} will release the plot and any subsequent
plotting will replace the previous plot.
variable \varcode{y} in the \entermde{Arbeitsbereich}{workspace} that
contains the measurement data it is enough to call
\code[plot()]{plot(y)}. At the first call of this function a new
\enterm{figure} will be opened and the data will be plotted with as a
line plot. If you repeatedly call this function the current plot will
be replaced unless the \code[hold]{hold on} command was issued
before. If it was, the current plot is held and a second line will be
added to it. Calling \code[hold]{hold off} will release the plot and
any subsequent plotting will replace the previous plot.
In our previous call to \varcode{plot} we provided just a single
variable containing the y-values of the plot. The x-axis will be
@ -375,7 +375,7 @@ purpose. For example, we have a number of measurements of a system's
response to a certain stimulus intensity. There is no dependency
between the data points, drawing them with a line-plot would be
nonsensical (figure\,\ref{scatterplotfig}\,A). In contrast to
\codeterm{}{plot} we need to provide x- and y-coordinates in order to
\code{plot()} we need to provide x- and y-coordinates in order to
draw the data. In the example we also provide further arguments to set
the size, color of the dots and specify that they are filled
(listing\,\ref{scatterlisting1}).

108
programming/lecture/programming.tex
View File

@ -76,13 +76,15 @@ z =
Line 1 can be read like: ``Create a variable with the name \varcode{x}
and assign the value 38''. The equality sign is the so called
\codeterm[Operator!assignment]{assignment operator}. Line 5 defines a variable \varcode{y}
and assigns an empty value. If not explicitly specified \matlab{}
variables will have the \codeterm{double} (a numeric data type, see
below) data type. In line 9, however, we create a variable \varcode{z}
and assign the character ``A'' to it. Accordingly, \varcode{z} does
not have the numeric \codeterm{double} data type but is of the type
\codeterm{character}. \textbf{Note:} \matlab{} uses single quotes for characters or strings of characters.
\entermde[Operator!assignment]{Operator!Zuweisungs@Zuweisungs\texttildelow}{assignment
operator}. Line 5 defines a variable \varcode{y} and assigns an
empty value. If not explicitly specified \matlab{} variables will have
the \code{double} (a numeric data type, see below) data type. In
line 9, however, we create a variable \varcode{z} and assign the
character ``A'' to it. Accordingly, \varcode{z} does not have the
numeric \code{double} data type but is a
\enterm{character} type. \textbf{Note:} \matlab{} uses single quotes for
both characters or strings of characters.
There are two ways to find out the actual data type of a variable: the
\code{class()} and the \code{whos} functions. While \code{class()}
@ -121,7 +123,7 @@ x y z
\pagebreak[4]
\subsection{Working with variables}
We can certainly work, i.e. do calculations, with variables. \matlab{}
knows all basic \codeterm[Operator!arithmetic]{arithmetic operators}
knows all basic \entermde[Operator!arithmetic]{Operator!arithmetischer}{arithmetic operators}
such as \code[Operator!arithmetic!1add@+]{+},
\code[Operator!arithmetic!2sub@-]{-},
\code[Operator!arithmetic!3mul@*]{*} and
@ -164,17 +166,17 @@ their values. Whenever the value of a variable should change, the
As mentioned above, the data type associated with a variable defines how the stored bit pattern is interpreted. The major data types are:
\begin{itemize}
\item \codeterm{integer}: Integer numbers. There are several subtypes
\item \enterm{integer}: Integer numbers. There are several subtypes
which, for most use-cases, can be ignored when working in \matlab{}.
\item \codeterm{single} \codeterm{double}: Floating point numbers. In
\item \enterm{single} \enterm{double}: Floating point numbers. In
contrast to the real numbers that are represented with this data
type the number of numeric values that can be represented is limited
(countable).
\item \codeterm{complex}: Complex numbers having a real and imaginary
\item \enterm{complex}: Complex numbers having a real and imaginary
part.
\item \codeterm{logical}: Boolean values that can be evaluated to
\item \enterm{logical}: Boolean values that can be evaluated to
\code{true} or \code{false}.
\item \codeterm{char}: ASCII characters.
\item \enterm{character}: ASCII characters.
\end{itemize}
There is a variety of numeric data types that require different
amounts of memory and have different ranges of values that can be
@ -196,7 +198,7 @@ represented (table~\ref{dtypestab}).
\end{tabular}
\end{table}
By default \matlab{} uses the \codeterm{double} data type whenever
By default \matlab{} uses the \enterm{double} data type whenever
numerical values are stored. Nevertheless, there are use-cases
in which different data types are better suited. Box~\ref{daqbox}
exemplifies one of such cases.
@ -229,7 +231,7 @@ exemplifies one of such cases.
In this context it is most efficient to store the measured values as
\code{int16} instead of \code{double} numbers. Storing floating
point numbers requires four times more memory (8 instead of 2
\codeterm{Byte}, 64 instead of 16 bit) and offers no additional
bytes, 64 instead of 16 bit) and offers no additional
information.
\end{ibox}
@ -338,8 +340,8 @@ ans =
The content of a vector is accessed using the element's index
(figure~\ref{vectorindexingfig}). Each element has an individual
\codeterm{index} that ranges (int \matlab{}) from 1 to the number of
elements irrespective of the type of vector.
\entermde{Index}{index} that ranges (int \matlab{}) from 1 to the
number of elements irrespective of the type of vector.
\begin{figure}[ht]
\includegraphics[width=0.4\columnwidth]{arrayIndexing}
@ -350,7 +352,7 @@ elements irrespective of the type of vector.
\begin{important}[Indexing]
Elements of a vector are accessed via their index. This process is
called \codeterm{indexing}.
called \entermde{Indizierung}{indexing}.
In \matlab{} the first element has the index one.
@ -651,7 +653,7 @@ elements of a matrix by it's index. Similar to a coordinate system
each element is addressed using an n-tuple with $n$ the number of
dimensions (figure~\ref{matrixindexingfig},
listing~\ref{matrixIndexing}). This type of indexing is called
\codeterm{subscript indexing}. The first coordinate refers always to
\enterm[indexing!subscript]{subscript indexing}. The first coordinate refers always to
the row, the second to the column, the third to the page, and so on.
\begin{lstlisting}[caption={Accessing elements in matrices, indexing.}, label=matrixIndexing]
@ -835,9 +837,9 @@ values (\varcode{true} or \varcode{false}). This implies that we need
only a single bit to store this information as 0 (false) or 1 (true)
It would be a waste of space to use more than one bit for
it. Accordingly, \matlab{} knows a special data type
(\codeterm{logical}) to store such information efficiently. \matlab{}
(\enterm{logical}) to store such information efficiently. \matlab{}
also knows the keywords \code{true} and \code{false} which are
synonymous for the \codeterm{logical} values 1 and
synonymous for the logical values 1 and
0. Listing~\ref{logicaldatatype} exemplifies the use of the logical
data type.
@ -884,10 +886,11 @@ table~\ref{logicaloperators}) which are introduced in the following
sections.
\subsection{Relational operators}
With \codeterm[Operator!relational]{relational operators}
(table~\ref{relationaloperators}) we can ask questions such as: ''Is
the value of variable \varcode{a} larger than the value of
\varcode{b}?'' or ``Is the value in \varcode{a} equal to the one
With
\entermde[Operator!relational]{Operator!Vergleichs@Vergleichs\texttildelow}{relational
operators} (table~\ref{relationaloperators}) we can ask questions
such as: ''Is the value of variable \varcode{a} larger than the value
of \varcode{b}?'' or ``Is the value in \varcode{a} equal to the one
stored in variable \varcode{b}?''.
\begin{table}[h!]
@ -943,7 +946,7 @@ number is greater than a certain threshold (\varcode{x > 0.25}). But what
if we wanted to check whether the number falls into the range greater
than 0.25 but less than 0.75? Numbers that fall into this range must
satisfy the one and the other condition. With
\codeterm[Operator!logical]{logical
\entermde[Operator!logical]{Operator!logischer}{logical
operators} (table~\ref{logicaloperators}) single Boolean expressions
can be joined to form more complex Boolean operations.
@ -1071,7 +1074,7 @@ values stored in a vector or matrix. It is very powerful and, once
understood, very intuitive.
The basic concept is that applying a Boolean operation on a vector
results in a \codeterm{logical} vector of the same size (see
results in a \enterm{logical} vector of the same size (see
listing~\ref{logicaldatatype}). This logical vector is then used to
select only those values for which the logical vector is true. Line 14
in listing~\ref{logicalindexing1} can be read: ``Select all those
@ -1152,14 +1155,14 @@ segment of data of a certain time span (the stimulus was on,
this if downward compatibility is desired/needed.}
\textbf{Structures} Arrays of named fields that each can contain
arbitrary data types. \codeterm{Structures} can have sub-structures
arbitrary data types. \enterm{Structures} can have sub-structures
and thus can build a trees. Structures are often used to combine
data and metadata in a single variable.
\textbf{Cell arrays} Arrays of variables that contain different
types. Unlike structures, the entries of a \codeterm{cell array} are
not named. Indexing in \codeterm[cell array]{cell arrays} requires a
special operator the \code{\{\}}. \matlab{} uses \codeterm[cell
types. Unlike structures, the entries of a \enterm{cell array} are
not named. Indexing in \enterm[cell array]{cell arrays} requires a
special operator the \code{\{\}}. \matlab{} uses \enterm[cell
array]{cell arrays} for example when strings of different lengths
should be stored in the same variable: \varcode{months = \{'Januar',
'February', 'March', 'April', 'May', 'Jun'\};}. Note the curly
@ -1167,14 +1170,14 @@ segment of data of a certain time span (the stimulus was on,
indexing.
\textbf{Tables} Tabular structure that allows to have columns of
varying type combined with a header (much like a spreadsheet).
different types combined with a header (much like a spreadsheet).
\textbf{Timetables} Array of values that are associated with a
timestamp. For example one can store measurements, that are made in
irregular intervals togehter with the measurement time in a single
variable. Without the \codeterm{Timetable} data type at least two
variable. Without the \enterm{Timetable} data type at least two
variables (one storing the time, the other the measurement) would be
required. \codeterm[Timetable]{Timetables} offer specific
required. \enterm[Timetable]{Timetables} offer specific
convenience functions to work with timestamps.
\textbf{Maps} In a \code{containers.Map} a \entermde{Wert}{value} is
@ -1185,8 +1188,8 @@ segment of data of a certain time span (the stimulus was on,
\textbf{Categorical arrays} are used to stored values that come from
a limited set of values, e.g. Months. Such categories can then be
used for filter operations. \codeterm{Categorical arrays} are often
used in conjunctions with \codeterm{Tables}.
used for filter operations. \enterm{Categorical arrays} are often
used in conjunctions with \enterm{Tables}.
\begin{lstlisting}[caption={Using Categorical arrays}, label=categoricallisting]
>> months = categorical({'Jan', 'Feb', 'Jan', 'Dec'});
>> events = [10, 2, 18, 20 ];
@ -1495,22 +1498,22 @@ and executed line-by-line from top to bottom.
\item \entermde[Object]{Objekte}{Objects} (not covered here)
\end{enumerate}
Programs are stored in so called \codeterm[m-file]{m-files}
Programs are stored in so called \entermde[m-file]{m-File}{m-files}
(e.g. \file{myProgram.m}). To use them they have to be \emph{called}
from the command line or from within another program. Storing your code in
programs increases the re-usability. So far we have used
from the command line or from within another program. Storing your
code in programs increases the re-usability. So far we have used
\emph{scripts} to store the solutions of the exercises. Any variable
that was created appeared in the \codeterm{workspace} and existed even
after the program was finished. This is very convenient but also bears
some risks. Consider the case that \file{script\_a.m} creates a
certain variable and assigns a value to it for later use. Now it calls
a second program (\file{script\_b.m}) that, by accident, uses the same
variable name and assigns a different value to it. When
\file{script\_b.m} is done, the control returns to \file{script\_a.m}
and if it now wants to read the previously stored variable, it will
contain a different value than expected. Bugs like this are hard to
find since each of the programs alone is perfectly fine and works as
intended. A solution for this problem are the
that was created appeared in the \entermde{Arbeitsbereich}{workspace}
and existed even after the program was finished. This is very
convenient but also bears some risks. Consider the case that
\file{script\_a.m} creates a certain variable and assigns a value to
it for later use. Now it calls a second program (\file{script\_b.m})
that, by accident, uses the same variable name and assigns a different
value to it. When \file{script\_b.m} is done, the control returns to
\file{script\_a.m} and if it now wants to read the previously stored
variable, it will contain a different value than expected. Bugs like
this are hard to find since each of the programs alone is perfectly
fine and works as intended. A solution for this problem are the
\entermde[function]{Funktion}{functions}.
\subsection{Functions}
@ -1533,8 +1536,9 @@ argument(s). The function head is then followed by the function's
body. A function is ended by and \code{end} (this is in fact optional
but we will stick to this). Each function that should be directly used
by the user (or called from other programs) should reside in an
individual \codeterm{m-file} that has the same name as the function. By
using functions instead of scripts we gain several advantages:
individual \entermde{m-File}{m-file} that has the same name as the
function. By using functions instead of scripts we gain several
advantages:
\begin{itemize}
\item Encapsulation of program code that solves a certain task. It can
be easily re-used in other programs.