removed \codeterm (replaced by \entermde)
This commit is contained in:
parent
c063cc9f0e
commit
39a1e51bc4
@ -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
|
results. Applying this structure makes it easy to understand the flow
|
||||||
of the program but two questions remain: (i) How to organize the files
|
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
|
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
|
Upon installation \matlab{} creates a folder called \file{MATLAB} in
|
||||||
the user space (Windows: My files, Linux: Documents, MacOS:
|
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
|
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
|
the same folder on the hard drive. An easy approach is to create a
|
||||||
project-specific folder structure that contains sub-folders for each
|
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
|
(screenshot \ref{fileorganizationfig}). In these task-related folders
|
||||||
one may consider to create a further sub-folder to store results
|
one may consider to create a further sub-folder to store results
|
||||||
(created figures, result data). On the project level a single script
|
(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}
|
\begin{ibox}[tp]{\label{matlabpathbox}\matlab{} search path}
|
||||||
The \codeterm{search path} defines where \matlab{} looks for scripts
|
The \entermde{Suchpfad}{search path} defines where \matlab{} looks
|
||||||
and functions. When calling a function from the command line
|
for scripts and functions. When calling a function from the command
|
||||||
\matlab{} needs to figure out which function is addressed and starts
|
line \matlab{} needs to figure out which function is addressed and
|
||||||
looking for it in the current path. If this fails it will crawl all
|
starts looking for it in the current path. If this fails it will
|
||||||
locations listed in the search path (see figure). The
|
crawl all locations listed in the search path (see figure). The
|
||||||
\codeterm{search path} is basically a list of folders. \matlab{}
|
\entermde{Suchpfad}{search path} is basically a list of
|
||||||
will go through this list from front to end and the search will stop
|
folders. \matlab{} will go through this list from front to end and
|
||||||
on the first match. This implies that the order in the search path
|
the search will stop on the first match. This implies that the order
|
||||||
may affect which version of functions that share the same name is
|
in the search path may affect which version of functions that share
|
||||||
used. Note: \matlab{} does not perform a recursive search. That is,
|
the same name is used. Note: \matlab{} does not perform a recursive
|
||||||
a function that resides in a sub-folder that is not explicitly
|
search. That is, a function that resides in a sub-folder that is not
|
||||||
listed in the \codeterm{search path} will not be found.
|
explicitly listed in the \entermde{Suchpfad}{search path} will not be found.
|
||||||
|
|
||||||
\vspace{2ex}
|
\vspace{2ex}
|
||||||
\includegraphics[width=0.9\textwidth]{search_path}
|
\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
|
this, one could also consider to delegate the respective task to a
|
||||||
function. In most cases this is preferable.
|
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
|
which can be confusing. Sometimes such a code is called ``spaghetti
|
||||||
code''. It is high time to think about delegation of tasks to
|
code''. It is high time to think about delegation of tasks to
|
||||||
functions.
|
functions.
|
||||||
@ -323,9 +323,9 @@ functions.
|
|||||||
\end{important}
|
\end{important}
|
||||||
|
|
||||||
\subsection{Local and nested functions}
|
\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
|
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
|
which increases complexity and may lead to confusion. If the delegated
|
||||||
functionality is used in multiple instances, it is still advisable to
|
functionality is used in multiple instances, it is still advisable to
|
||||||
do so. On the other hand, when the delegated functionality is only
|
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
|
within the same file. Listing \ref{localfunctions} shows an example of
|
||||||
a local function definition.
|
a local function definition.
|
||||||
|
|
||||||
\pagebreak[3] \lstinputlisting[label=localfunctions, caption={Example
|
\pagebreak[3]
|
||||||
for local functions.}]{calculateSines.m}
|
\lstinputlisting[label=localfunctions, caption={Example for local
|
||||||
|
functions.}]{calculateSines.m}
|
||||||
|
|
||||||
\emph{Local function} live in the same \codeterm{m-file} as the main
|
\emph{Local function} live in the same \entermde{m-File}{m-file} as
|
||||||
function and are only available in this context. Each local function
|
the main function and are only available in this context. Each local
|
||||||
has its own \codeterm{scope}, that is, the local function can not
|
function has its own \enterm{scope}, that is, the local function can
|
||||||
access (read or write) variables of the calling function. Interaction
|
not access (read or write) variables of the calling
|
||||||
with the local function requires to pass all required arguments and to
|
function. Interaction with the local function requires to pass all
|
||||||
take care of the return values of the function.
|
required arguments and to take care of the return values of the
|
||||||
|
function.
|
||||||
|
|
||||||
\emph{Nested functions} are different in this respect. They are
|
\emph{Nested functions} are different in this respect. They are
|
||||||
defined within the body of the parent function (between the keywords
|
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}
|
\section{Specifics when using scripts}
|
||||||
A similar problem as with nested function arises 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
|
(instead of functions). All variables that are defined within a script
|
||||||
become available in the global \codeterm{workspace}. There is the risk
|
become available in the global \enterm{workspace}
|
||||||
of name conflicts, that is, a called sub-script redefines or uses the
|
(\determ{Arbeitsbereich}). There is the risk of name conflicts, that
|
||||||
same variable name and may \emph{silently} change its content. The
|
is, a called sub-script redefines or uses the same variable name and
|
||||||
user will not be notified about this change and the calling script may
|
may \emph{silently} change its content. The user will not be notified
|
||||||
expect a completely different content. Bugs that are based on such
|
about this change and the calling script may expect a completely
|
||||||
mistakes are hard to find since the program itself looks perfectly
|
different content. Bugs that are based on such mistakes are hard to
|
||||||
fine.
|
find since the program itself looks perfectly fine.
|
||||||
|
|
||||||
To avoid such issues one should design scripts in a way that they
|
To avoid such issues one should design scripts in a way that they
|
||||||
perform their tasks independent from other scripts and functions.
|
perform their tasks independent from other scripts and functions.
|
||||||
|
@ -228,11 +228,6 @@
|
|||||||
% the german index.
|
% the german index.
|
||||||
\newcommand{\determ}[2][]{``#2''\ifthenelse{\equal{#1}{}}{\protect\sindex[determ]{#2}}{\protect\sindex[determ]{#1}}}
|
\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}}
|
\newcommand{\file}[1]{\texttt{#1}}
|
||||||
|
|
||||||
% for escaping special characters into the index:
|
% for escaping special characters into the index:
|
||||||
|
@ -93,15 +93,15 @@ number of datasets.
|
|||||||
\subsection{Simple plotting}
|
\subsection{Simple plotting}
|
||||||
|
|
||||||
Creating a simple line-plot is rather easy. Assuming there exists a
|
Creating a simple line-plot is rather easy. Assuming there exists a
|
||||||
variable \varcode{y} in the \codeterm{workspace} that contains the
|
variable \varcode{y} in the \entermde{Arbeitsbereich}{workspace} that
|
||||||
measurement data it is enough to call \code[plot()]{plot(y)}. At the
|
contains the measurement data it is enough to call
|
||||||
first call of this function a new \codeterm{figure} will be opened and
|
\code[plot()]{plot(y)}. At the first call of this function a new
|
||||||
the data will be plotted with as a line plot. If you repeatedly call
|
\enterm{figure} will be opened and the data will be plotted with as a
|
||||||
this function the current plot will be replaced unless the
|
line plot. If you repeatedly call this function the current plot will
|
||||||
\code[hold]{hold on} command was issued before. If it was, the current
|
be replaced unless the \code[hold]{hold on} command was issued
|
||||||
plot is held and a second line will be added to it. Calling
|
before. If it was, the current plot is held and a second line will be
|
||||||
\code[hold]{hold off} will release the plot and any subsequent
|
added to it. Calling \code[hold]{hold off} will release the plot and
|
||||||
plotting will replace the previous plot.
|
any subsequent plotting will replace the previous plot.
|
||||||
|
|
||||||
In our previous call to \varcode{plot} we provided just a single
|
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
|
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
|
response to a certain stimulus intensity. There is no dependency
|
||||||
between the data points, drawing them with a line-plot would be
|
between the data points, drawing them with a line-plot would be
|
||||||
nonsensical (figure\,\ref{scatterplotfig}\,A). In contrast to
|
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
|
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
|
the size, color of the dots and specify that they are filled
|
||||||
(listing\,\ref{scatterlisting1}).
|
(listing\,\ref{scatterlisting1}).
|
||||||
|
@ -76,13 +76,15 @@ z =
|
|||||||
|
|
||||||
Line 1 can be read like: ``Create a variable with the name \varcode{x}
|
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
|
and assign the value 38''. The equality sign is the so called
|
||||||
\codeterm[Operator!assignment]{assignment operator}. Line 5 defines a variable \varcode{y}
|
\entermde[Operator!assignment]{Operator!Zuweisungs@Zuweisungs\texttildelow}{assignment
|
||||||
and assigns an empty value. If not explicitly specified \matlab{}
|
operator}. Line 5 defines a variable \varcode{y} and assigns an
|
||||||
variables will have the \codeterm{double} (a numeric data type, see
|
empty value. If not explicitly specified \matlab{} variables will have
|
||||||
below) data type. In line 9, however, we create a variable \varcode{z}
|
the \code{double} (a numeric data type, see below) data type. In
|
||||||
and assign the character ``A'' to it. Accordingly, \varcode{z} does
|
line 9, however, we create a variable \varcode{z} and assign the
|
||||||
not have the numeric \codeterm{double} data type but is of the type
|
character ``A'' to it. Accordingly, \varcode{z} does not have the
|
||||||
\codeterm{character}. \textbf{Note:} \matlab{} uses single quotes for characters or strings of characters.
|
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
|
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()}
|
\code{class()} and the \code{whos} functions. While \code{class()}
|
||||||
@ -121,7 +123,7 @@ x y z
|
|||||||
\pagebreak[4]
|
\pagebreak[4]
|
||||||
\subsection{Working with variables}
|
\subsection{Working with variables}
|
||||||
We can certainly work, i.e. do calculations, with variables. \matlab{}
|
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@+]{+},
|
such as \code[Operator!arithmetic!1add@+]{+},
|
||||||
\code[Operator!arithmetic!2sub@-]{-},
|
\code[Operator!arithmetic!2sub@-]{-},
|
||||||
\code[Operator!arithmetic!3mul@*]{*} and
|
\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:
|
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}
|
\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{}.
|
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
|
contrast to the real numbers that are represented with this data
|
||||||
type the number of numeric values that can be represented is limited
|
type the number of numeric values that can be represented is limited
|
||||||
(countable).
|
(countable).
|
||||||
\item \codeterm{complex}: Complex numbers having a real and imaginary
|
\item \enterm{complex}: Complex numbers having a real and imaginary
|
||||||
part.
|
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}.
|
\code{true} or \code{false}.
|
||||||
\item \codeterm{char}: ASCII characters.
|
\item \enterm{character}: ASCII characters.
|
||||||
\end{itemize}
|
\end{itemize}
|
||||||
There is a variety of numeric data types that require different
|
There is a variety of numeric data types that require different
|
||||||
amounts of memory and have different ranges of values that can be
|
amounts of memory and have different ranges of values that can be
|
||||||
@ -196,7 +198,7 @@ represented (table~\ref{dtypestab}).
|
|||||||
\end{tabular}
|
\end{tabular}
|
||||||
\end{table}
|
\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
|
numerical values are stored. Nevertheless, there are use-cases
|
||||||
in which different data types are better suited. Box~\ref{daqbox}
|
in which different data types are better suited. Box~\ref{daqbox}
|
||||||
exemplifies one of such cases.
|
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
|
In this context it is most efficient to store the measured values as
|
||||||
\code{int16} instead of \code{double} numbers. Storing floating
|
\code{int16} instead of \code{double} numbers. Storing floating
|
||||||
point numbers requires four times more memory (8 instead of 2
|
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.
|
information.
|
||||||
\end{ibox}
|
\end{ibox}
|
||||||
|
|
||||||
@ -338,8 +340,8 @@ ans =
|
|||||||
|
|
||||||
The content of a vector is accessed using the element's index
|
The content of a vector is accessed using the element's index
|
||||||
(figure~\ref{vectorindexingfig}). Each element has an individual
|
(figure~\ref{vectorindexingfig}). Each element has an individual
|
||||||
\codeterm{index} that ranges (int \matlab{}) from 1 to the number of
|
\entermde{Index}{index} that ranges (int \matlab{}) from 1 to the
|
||||||
elements irrespective of the type of vector.
|
number of elements irrespective of the type of vector.
|
||||||
|
|
||||||
\begin{figure}[ht]
|
\begin{figure}[ht]
|
||||||
\includegraphics[width=0.4\columnwidth]{arrayIndexing}
|
\includegraphics[width=0.4\columnwidth]{arrayIndexing}
|
||||||
@ -350,7 +352,7 @@ elements irrespective of the type of vector.
|
|||||||
|
|
||||||
\begin{important}[Indexing]
|
\begin{important}[Indexing]
|
||||||
Elements of a vector are accessed via their index. This process is
|
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.
|
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
|
each element is addressed using an n-tuple with $n$ the number of
|
||||||
dimensions (figure~\ref{matrixindexingfig},
|
dimensions (figure~\ref{matrixindexingfig},
|
||||||
listing~\ref{matrixIndexing}). This type of indexing is called
|
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.
|
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]
|
\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)
|
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 would be a waste of space to use more than one bit for
|
||||||
it. Accordingly, \matlab{} knows a special data type
|
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
|
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
|
0. Listing~\ref{logicaldatatype} exemplifies the use of the logical
|
||||||
data type.
|
data type.
|
||||||
|
|
||||||
@ -884,10 +886,11 @@ table~\ref{logicaloperators}) which are introduced in the following
|
|||||||
sections.
|
sections.
|
||||||
|
|
||||||
\subsection{Relational operators}
|
\subsection{Relational operators}
|
||||||
With \codeterm[Operator!relational]{relational operators}
|
With
|
||||||
(table~\ref{relationaloperators}) we can ask questions such as: ''Is
|
\entermde[Operator!relational]{Operator!Vergleichs@Vergleichs\texttildelow}{relational
|
||||||
the value of variable \varcode{a} larger than the value of
|
operators} (table~\ref{relationaloperators}) we can ask questions
|
||||||
\varcode{b}?'' or ``Is the value in \varcode{a} equal to the one
|
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}?''.
|
stored in variable \varcode{b}?''.
|
||||||
|
|
||||||
\begin{table}[h!]
|
\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
|
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
|
than 0.25 but less than 0.75? Numbers that fall into this range must
|
||||||
satisfy the one and the other condition. With
|
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
|
operators} (table~\ref{logicaloperators}) single Boolean expressions
|
||||||
can be joined to form more complex Boolean operations.
|
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.
|
understood, very intuitive.
|
||||||
|
|
||||||
The basic concept is that applying a Boolean operation on a vector
|
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
|
listing~\ref{logicaldatatype}). This logical vector is then used to
|
||||||
select only those values for which the logical vector is true. Line 14
|
select only those values for which the logical vector is true. Line 14
|
||||||
in listing~\ref{logicalindexing1} can be read: ``Select all those
|
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.}
|
this if downward compatibility is desired/needed.}
|
||||||
|
|
||||||
\textbf{Structures} Arrays of named fields that each can contain
|
\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
|
and thus can build a trees. Structures are often used to combine
|
||||||
data and metadata in a single variable.
|
data and metadata in a single variable.
|
||||||
|
|
||||||
\textbf{Cell arrays} Arrays of variables that contain different
|
\textbf{Cell arrays} Arrays of variables that contain different
|
||||||
types. Unlike structures, the entries of a \codeterm{cell array} are
|
types. Unlike structures, the entries of a \enterm{cell array} are
|
||||||
not named. Indexing in \codeterm[cell array]{cell arrays} requires a
|
not named. Indexing in \enterm[cell array]{cell arrays} requires a
|
||||||
special operator the \code{\{\}}. \matlab{} uses \codeterm[cell
|
special operator the \code{\{\}}. \matlab{} uses \enterm[cell
|
||||||
array]{cell arrays} for example when strings of different lengths
|
array]{cell arrays} for example when strings of different lengths
|
||||||
should be stored in the same variable: \varcode{months = \{'Januar',
|
should be stored in the same variable: \varcode{months = \{'Januar',
|
||||||
'February', 'March', 'April', 'May', 'Jun'\};}. Note the curly
|
'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.
|
indexing.
|
||||||
|
|
||||||
\textbf{Tables} Tabular structure that allows to have columns of
|
\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
|
\textbf{Timetables} Array of values that are associated with a
|
||||||
timestamp. For example one can store measurements, that are made in
|
timestamp. For example one can store measurements, that are made in
|
||||||
irregular intervals togehter with the measurement time in a single
|
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
|
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.
|
convenience functions to work with timestamps.
|
||||||
|
|
||||||
\textbf{Maps} In a \code{containers.Map} a \entermde{Wert}{value} is
|
\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
|
\textbf{Categorical arrays} are used to stored values that come from
|
||||||
a limited set of values, e.g. Months. Such categories can then be
|
a limited set of values, e.g. Months. Such categories can then be
|
||||||
used for filter operations. \codeterm{Categorical arrays} are often
|
used for filter operations. \enterm{Categorical arrays} are often
|
||||||
used in conjunctions with \codeterm{Tables}.
|
used in conjunctions with \enterm{Tables}.
|
||||||
\begin{lstlisting}[caption={Using Categorical arrays}, label=categoricallisting]
|
\begin{lstlisting}[caption={Using Categorical arrays}, label=categoricallisting]
|
||||||
>> months = categorical({'Jan', 'Feb', 'Jan', 'Dec'});
|
>> months = categorical({'Jan', 'Feb', 'Jan', 'Dec'});
|
||||||
>> events = [10, 2, 18, 20 ];
|
>> 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)
|
\item \entermde[Object]{Objekte}{Objects} (not covered here)
|
||||||
\end{enumerate}
|
\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}
|
(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
|
from the command line or from within another program. Storing your
|
||||||
programs increases the re-usability. So far we have used
|
code in programs increases the re-usability. So far we have used
|
||||||
\emph{scripts} to store the solutions of the exercises. Any variable
|
\emph{scripts} to store the solutions of the exercises. Any variable
|
||||||
that was created appeared in the \codeterm{workspace} and existed even
|
that was created appeared in the \entermde{Arbeitsbereich}{workspace}
|
||||||
after the program was finished. This is very convenient but also bears
|
and existed even after the program was finished. This is very
|
||||||
some risks. Consider the case that \file{script\_a.m} creates a
|
convenient but also bears some risks. Consider the case that
|
||||||
certain variable and assigns a value to it for later use. Now it calls
|
\file{script\_a.m} creates a certain variable and assigns a value to
|
||||||
a second program (\file{script\_b.m}) that, by accident, uses the same
|
it for later use. Now it calls a second program (\file{script\_b.m})
|
||||||
variable name and assigns a different value to it. When
|
that, by accident, uses the same variable name and assigns a different
|
||||||
\file{script\_b.m} is done, the control returns to \file{script\_a.m}
|
value to it. When \file{script\_b.m} is done, the control returns to
|
||||||
and if it now wants to read the previously stored variable, it will
|
\file{script\_a.m} and if it now wants to read the previously stored
|
||||||
contain a different value than expected. Bugs like this are hard to
|
variable, it will contain a different value than expected. Bugs like
|
||||||
find since each of the programs alone is perfectly fine and works as
|
this are hard to find since each of the programs alone is perfectly
|
||||||
intended. A solution for this problem are the
|
fine and works as intended. A solution for this problem are the
|
||||||
\entermde[function]{Funktion}{functions}.
|
\entermde[function]{Funktion}{functions}.
|
||||||
|
|
||||||
\subsection{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
|
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
|
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
|
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
|
individual \entermde{m-File}{m-file} that has the same name as the
|
||||||
using functions instead of scripts we gain several advantages:
|
function. By using functions instead of scripts we gain several
|
||||||
|
advantages:
|
||||||
\begin{itemize}
|
\begin{itemize}
|
||||||
\item Encapsulation of program code that solves a certain task. It can
|
\item Encapsulation of program code that solves a certain task. It can
|
||||||
be easily re-used in other programs.
|
be easily re-used in other programs.
|
||||||
|
Reference in New Issue
Block a user