Show
Ignore:
Timestamp:
10/15/09 00:10:19 (15 years ago)
Author:
smidl
Message:

doc

Files:
1 copied

Legend:

Unmodified
Added
Removed
  • library/doc/html/userguide.html

    r656 r661  
    6363 
    6464 
    65 <h1><a class="anchor" id="user_guide">BDM Use - System, Data, Simulation </a></h1><p>This section serves as introdustion to the scenario of data simulation. Since it is the simpliest of all scenarios defined in <a class="el" href="user_guide0.html">BDM Use - Introduction</a> it also serves as introduction to configuration of an experiment (see <a class="el" href="ui_page.html">User Infos and their use</a>) and basic decision making objects (<a class="el" href="classbdm_1_1RV.html" title="Class representing variables, most often random variables.">bdm::RV</a> and <a class="el" href="classbdm_1_1DS.html" title="Abstract class for discrete-time sources of data.">bdm::DS</a>).</p> 
     65<h1><a class="anchor" id="userguide">BDM Use - System, Data, Simulation </a></h1><p>This section serves as introdustion to the scenario of data simulation. Since it is the simpliest of all scenarios defined in <a class="el" href="userguide0.html">BDM Use - Introduction</a> it also serves as introduction to configuration of an experiment (see <a class="el" href="ui.html">User Infos and their use</a>) and basic decision making objects (<a class="el" href="classbdm_1_1RV.html" title="Class representing variables, most often random variables.">bdm::RV</a> and <a class="el" href="classbdm_1_1DS.html" title="Abstract class for discrete-time sources of data.">bdm::DS</a>).</p> 
    6666<p>All experiments are demonstarted on scenario simulator which can be either standalone application or mex file (simulator.mex**).</p> 
    6767<h2><a class="anchor" id="ug_config"> 
     
    7171<p>The configuration has two possible options:</p> 
    7272<ul> 
    73 <li>configuration file using syntax of libconfig (see <a class="el" href="ui_page.html">User Infos and their use</a>),</li> 
    74 <li>matlab structure. For the purpose of tutorial, we will use the matlab notation. These two options can be mutually converted from one to another using prepared mex files: config2mxstruct.mex and mxstruct2config.mex. Naturally, these scripts require matlab to run. If it is not available, manual conversion is relatively trivial, the major difference is in using different types of brackets (<a class="el" href="ui_page.html">User Infos and their use</a>)</li> 
     73<li>configuration file using syntax of libconfig (see <a class="el" href="ui.html">User Infos and their use</a>),</li> 
     74<li>matlab structure. For the purpose of tutorial, we will use the matlab notation. These two options can be mutually converted from one to another using prepared mex files: config2mxstruct.mex and mxstruct2config.mex. Naturally, these scripts require matlab to run. If it is not available, manual conversion is relatively trivial, the major difference is in using different types of brackets (<a class="el" href="ui.html">User Infos and their use</a>)</li> 
    7575</ul> 
    7676<h3><a class="anchor" id="ug_first"> 
     
    108108<h2><a class="anchor" id="ug_memds"> 
    109109DataSource of pre-recorded data -- MemDS</a></h2> 
    110 <p>The first experiment run in first was actually an instance of DataSource of pre-recorded data that were stored in memory, i.e. the <a class="el" href="classbdm_1_1MemDS.html" title="Memory storage of off-line data column-wise.">bdm::MemDS</a> class.</p> 
     110<p>The first experiment run in <a class="el" href="userguide.html#ug_first">First experiment</a> was actually an instance of DataSource of pre-recorded data that were stored in memory, i.e. the <a class="el" href="classbdm_1_1MemDS.html" title="Memory storage of off-line data column-wise.">bdm::MemDS</a> class.</p> 
    111111<p>Operation of such object is trivial, the data are stored as a matrix and the general operations defined above are specialized as follows:</p> 
    112112<ol type="1"> 
     
    155155ug_rv_connect</a></h3> 
    156156<p>The <code>simulator</code> scenario connects the DataSource to second basic class of BDM, bdm:logger. The logger is a class that take care of storing results -- in this case, results of simulation. The connection between these blocks is done automatically. The logger stores results of simulations under the names specified in drv. 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.</p> 
    157 <h2><a class="anchor" id="loggers"> 
     157<h2><a class="anchor" id="ug_loggers"> 
    158158Loggers for flexible handling of results</a></h2> 
    159159<p>Loggers are universal objects for storing and manipulating the results of an experiment. Similar to DataSource, every logger has to provide basic functionality:</p> 
     
    181181</li> 
    182182<li><a class="el" href="classbdm_1_1MpdfDS.html" title="Simulate data from conditional density Still having only one density but allowing...">bdm::MpdfDS</a></li> 
    183 <li><a class="el" href="classbdm_1_1stateDS.html">bdm::stateDS</a></li> 
    184 </ul> 
    185 <p>The MemDS has already been introduced in the example in memds. However, any of the classes listed above can be used to replace it in the example. This will be demonstrated on the <code>EpdfDS</code> class.</p> 
     183<li><a class="el" href="classbdm_1_1stateDS.html" title="State-space data source simulating two densities.">bdm::stateDS</a></li> 
     184</ul> 
     185<p>The MemDS has already been introduced in the example in <a class="el" href="userguide.html#ug_memds">DataSource of pre-recorded data -- MemDS</a>. However, any of the classes listed above can be used to replace it in the example. This will be demonstrated on the <code>EpdfDS</code> class.</p> 
    186186<p>Brief decription of the class states that EpdfDS "Simulate data from a static pdf (epdf)". The static pdf means unconditional pdf in the sense that the random variable is conditioned by numerical values only. In mathematical notation it could be both <img class="formulaInl" alt="$ f(a) $" src="form_137.png"/> and <img class="formulaInl" alt="$ f(x_t |d_1 \ldots d_t)$" src="form_138.png"/>. The latter case is true only when all <img class="formulaInl" alt="$ d $" src="form_139.png"/> denotes observed values.</p> 
    187187<p>For example, we wish to simulate realizations of a Uniform pdf on interval &lt;-1,1&gt;. This is achieved by plugging an object representing uniform pdf into general simulator of independent random samples, EpdfDS. Uniform density is implemented as class <a class="el" href="classbdm_1_1euni.html" title="Uniform distributed density on a rectangular support.">bdm::euni</a>. An instance of <code>euni</code> can be again created method <code>from_setting</code>, in this case <a class="el" href="classbdm_1_1euni.html#a77f5fef1f006fe056066da23b9e5f042">bdm::euni.from_setting()</a>. Using documentation we define it with the following code: </p> 
     
    247247<ul> 
    248248<li>class of the <code>fy</code> object is 'mlnorm&lt;ldmat&gt;' which is Normal pdf with mean value given by linear function, and covariance matrix stored in LD decomposition, see <a class="el" href="classbdm_1_1mlnorm.html" title="Normal distributed linear function with linear function of mean value;.">bdm::mlnorm</a> for details.</li> 
    249 <li>naming convention 'mlnorm&lt;ldmat&gt;' 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&lt;ldmat&gt;, <a class="el" href="classbdm_1_1mlnorm.html">mlnorm&lt;chmat&gt;</a>, mlnorm&lt;fsqmat&gt;. Those classes act identically the only difference is that the internal data are stored either in LD decomposition, choleski decomposition or full matrices, respectively.</li> 
     249<li>naming convention 'mlnorm&lt;ldmat&gt;' 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&lt;ldmat&gt;, mlnorm&lt;chmat&gt;, mlnorm&lt;fsqmat&gt;. Those classes act identically the only difference is that the internal data are stored either in LD decomposition, choleski decomposition or full matrices, respectively.</li> 
    250250<li>the same concept is used for enorm, where <a class="el" href="classbdm_1_1enorm.html">enorm&lt;chmat&gt;</a> and <a class="el" href="classbdm_1_1enorm.html">enorm&lt;fsqmat&gt;</a> are also possible. In this particular use, these objects are equivalent. In specific situation, e.g. Kalman filter implemented on Choleski decomposition (<a class="el" href="classbdm_1_1KalmanCh.html" title="Kalman filter in square root form.">bdm::KalmanCh</a>), only <a class="el" href="classbdm_1_1enorm.html">enorm&lt;chmat&gt;</a> is approprate.</li> 
    251251<li>class 'mprod' represents the chain rule of probability. Attribute <code>mpdfs</code> of its configuration structure is a list of conditional densities. Conditional density <img class="formulaInl" alt="$ f(a|b)$" src="form_151.png"/> is represented by class <code>mpdf</code> and its offsprings. Class <code>RV</code> is used to describe both variables before conditioning (field <code>rv</code> ) and after conditioning sign (field <code>rvc</code>).</li> 
     
    272272mxDS.drv     = drv; 
    273273</pre></div> </div> 
    274 <hr size="1"/><address style="text-align: right;"><small>Generated on Mon Oct 12 19:37:19 2009 for mixpp by&nbsp; 
     274<hr size="1"/><address style="text-align: right;"><small>Generated on Thu Oct 15 00:07:48 2009 for mixpp by&nbsp; 
    275275<a href="http://www.doxygen.org/index.html"> 
    276276<img class="footer" src="doxygen.png" alt="doxygen"/></a> 1.6.1 </small></address>