Changeset 948 for library/doc/tutorial/01userguide_sim.dox

Timestamp:

05/18/10 16:54:25 (14 years ago)

Author:

smidl

Message:

doc

Files:

• library/doc/tutorial/01userguide_sim.dox (modified) (13 diffs)

library/doc/tutorial/01userguide_sim.dox

@@ -2 +2 @@
 \page userguide_sim BDM Use - System, Data, Simulation
 
-This section serves as introduction to the scenario of data simulation. Since it is the simpliest of all scenarios defined in \ref userguide0 it also serves as introduction to configuration of an experiment (see \ref ui) and basic decision making objects (bdm::RV and bdm::DS).
-
-All experiments are demonstarted on mex file \c simulator, which is also available as a standalone application.
+This section serves as introduction to the scenario of data simulation. Since it is the simplest of all scenarios defined in \ref userguide0 it also serves as introduction to configuration of an experiment (see \ref ui) and basic decision making objects (bdm::RV and bdm::DS).
+
+All experiments are demonstrated on mex file \c simulator, which is also available as a standalone application.
+
+Table of contents:
+\section ug_sim_config 
+\section ug_sim 
+\section ug_memds 
+\section ug_rvs 
+\subsection ug_rv_connect 
+\section ug_pdfds 
+\section ug_arx_sim 
+\subsection ug_ini 
+\section ug_store 
 
 
@@ -13 +24 @@
 Specific treatment was developed for objects. Since BDM is designed as object oriented library, the configuration was designed to honor the rule of inheritance. That is, offspring of a class can be used in place of its predecessor. Hence, objects (instances of classes) are configured by a structure  with compulsory field \c class. This is a string variable corresponding to the name of the class to be used. This information is stored in Matlab structures (or objects, see section on Matlab extensions).
 
-Advacnded users can find more information in (\ref ui).
+Advanced users can find more information in (\ref ui).
 
 \subsection ug_first First experiment
@@ -24 +35 @@
 which can be found in file bdmtoolbox/tutorials/userguide/memds_example.m.
 
-The code above is the minimum necessary information to run scenario \c simulator in matlab. 
-To actually do so, make sure that matlab paths are correctly set, as described in \ref install.
+The code above is the minimum necessary information to run scenario \c simulator in Matlab. 
+To actually do so, make sure that Matlab paths are correctly set, as described in \ref install.
 
 The expected result for Matlab is:
@@ -62 +73 @@
  -# store log of its activity into dedicated logger.
 
-No fruther specification, e.g. if the data are pre-recorded or computed on-the-fly, are given.
+No further specification, e.g. if the data are pre-recorded or computed on-the-fly, are given.
 For a list of available DataSources, see ...
 
@@ -71 +82 @@
 
 Operation of such object is trivial, the data are stored as a matrix and the general operations defined above are specialized as follows:
- -# data observed at time \f$ t \f$  are columns of the matrix, getdata() ruturns current column,
+ -# data observed at time \f$ t \f$  are columns of the matrix, getdata() returns current column,
  -# time step itself is performed by increasing the column index,
  -# each row is named as "ch0","ch1",...
 
-This is the default bahavior. It can be customized using the UI mechanism. Full list of options is:
+This is the default behavior. It can be customized using the UI mechanism. Full list of options is:
 \code
 DS.class = 'MemDS';
@@ -99 +110 @@
 
 It is used for:
- - desription of RV in pdfs, ways how to define marginalization and conditioning,
+ - description of RV in pdfs, ways how to define marginalization and conditioning,
  - connection between source of data and computational objects that use them,
  - connection <b>time</b>, more exactly time shift from \f$ t \f$, defaults to 0.
 
-For example, the estimators will request the data from the above mentioned data source by asking for rv 'ch0'. If a more meaninful names are available, the fields drv can be added to read:
+For example, the estimators will request the data from the above mentioned data source by asking for rv 'ch0'. If a more meaningful names are available, the fields drv can be added to read:
 \code
 DS.class='MemDS';
@@ -109 +120 @@
 DS.drv = RV('y');
 \endcode
-Data from thsi data source will be available when estimators ask for rv 'y'.
+Data from this data source will be available when estimators ask for rv 'y'.
 
 \subsection ug_rv_connect Storing results
 
-results of an experiment can be stored in many ways. This functionality was abstracted into a class called logger. Exact form of the stored resuls is chosen by choosing appropriate class.
-For example, \c stdlog writes all output in the console, \c dirfilelog writes all data in the dirfilelog format for high-speed data processing, \c mexlog writes data into matlab structure. 
+results of an experiment can be stored in many ways. This functionality was abstracted into a class called logger. Exact form of the stored results is chosen by choosing appropriate class.
+For example, \c stdlog writes all output in the console, \c dirfilelog writes all data in the dirfilelog format for high-speed data processing, \c mexlog writes data into Matlab structure. 
 The \c mexlog is the default option in bdmtoolbox.
 
-Connection between computational blocks and loggers is controlled by structure called \c log_level which governes the level of details to be logged.
+Connection between computational blocks and loggers is controlled by structure called \c log_level which governs the level of details to be logged.
 A standard Data source has two levels, \c logdt and \c logut which means "log all outputs, dt" and "log all inputs, ut".
 Readers familiar with Simulink environment may look at the RV as being unique identifiers of inputs and outputs of simulation blocks. The inputs are connected automatically with the outputs with matching RV. This view is however, very incomplete, RV have more roles than this.
@@ -134 +145 @@
 \f]
   
-The datasource itself, i.e. the instanc of \c EpdfDS can be then configured via:
+The datasource itself, i.e. the instance of \c EpdfDS can be then configured via:
 \code
 DS.class = 'pdfDS';
@@ -150 +161 @@
 
 If the task was only to generate random realizations, this would indeed be a very clumsy way of doing it. 
-However, the power of the proposed approach will be revelead in more demanding examples, one of which follows next.
+However, the power of the proposed approach will be revealed in more demanding examples, one of which follows next.
 
 By default, data from this datasouce will be named after the rvs in given by the pdfs. When pdf with no rv is used, drv of the data source is set again to 'ch0'.
@@ -164 +175 @@
 We need to handle two issues:
  -# extra unsimulated variable \f$ u \f$,
- -# time delayes of the values.
+ -# time delays of the values.
 
 The first issue can be handled in two ways. First, \f$ u \f$ can be considered as input and as such it could be externally given to the datasource. This solution is used in scenario \c closedloop.
@@ -202 +213 @@
 Explanation of this example will require few remarks:
  - class of the \c fy object is 'mlnorm\<ldmat\>' which is Normal pdf with mean value given by linear function, and covariance matrix stored in LD decomposition, see bdm::mlnorm for details.
- - naming convention 'mlnorm\<ldmat\>' relates to the concept of templates in C++. For those unfamiliar with this concept, it is basicaly a way how to share code for different flavours of the same object. Note that mlnorm exist in three versions: mlnorm\<ldmat\>, mlnorm<chmat>, mlnorm<fsqmat>. Those classes act identically the only difference is that the internal data are stored either in LD decomposition, choleski decomposition or full matrices, respectively. 
+ - naming convention 'mlnorm\<ldmat\>' relates to the concept of templates in C++. For those unfamiliar with this concept, it is basically a way how to share code for different flavors of the same object. Note that mlnorm exist in three versions: mlnorm\<ldmat\>, mlnorm<chmat>, mlnorm<fsqmat>. Those classes act identically the only difference is that the internal data are stored either in LD decomposition, choleski decomposition or full matrices, respectively. 
  - the same concept is used for enorm, where enorm<chmat> and enorm<fsqmat> are also possible. In this particular use, these objects are equivalent. In specific situation, e.g. Kalman filter implemented on Choleski decomposition (bdm::KalmanCh), only enorm<chmat> is approprate.
  - class 'mprod' represents the chain rule of probability, see \ref ug_pdf_cond.
  
-The code above can be immediatelly run, usin the same execution sequence of \c estimator as above. 
+The code above can be immediately run, using the same execution sequence of \c estimator as above. 
 
 \subsection ug_ini Initializing simulation
@@ -217 +228 @@
 
 The values of \c init_values will be copied to places in history identified by corresponding values of \c init_rv.
-Initial data is not checked for completeness, i.e. values of random variables missing from \c init_rv (in this case all occurences of \f$ u \f$) are still initialized to 0.
+Initial data is not checked for completeness, i.e. values of random variables missing from \c init_rv (in this case all occurrences of \f$ u \f$) are still initialized to 0.
 
 \section ug_store Storing results of simulation
@@ -226 +237 @@
 For example, the output of \c MemDS can be stored as an .it file (filename is specified in configuration structure) which can be later read by bdm::ITppFileDS.
 
-In matlab, the output of mexlog is a structure of vectors or matrices. The results can be saved in a matlab file using:
+In Matlab, the output of mexlog is a structure of vectors or matrices. The results can be saved in a Matlab file using:
 \code
 Data=[M.y; M.u];