Index: library/doc/html/user_guide.html
===================================================================
--- library/doc/html/user_guide.html (revision 656)
+++ library/doc/html/user_guide.html (revision 661)
@@ -108,5 +108,5 @@
 <h2><a class="anchor" id="ug_memds">
 DataSource of pre-recorded data -- MemDS</a></h2>
-<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>
+<p>The first experiment run in <a class="el" href="user_guide.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>
 <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>
 <ol type="1">
@@ -155,5 +155,5 @@
 ug_rv_connect</a></h3>
 <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>
-<h2><a class="anchor" id="loggers">
+<h2><a class="anchor" id="ug_loggers">
 Loggers for flexible handling of results</a></h2>
 <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>
@@ -181,7 +181,7 @@
 </li>
 <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>
-<li><a class="el" href="classbdm_1_1stateDS.html">bdm::stateDS</a></li>
-</ul>
-<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>
+<li><a class="el" href="classbdm_1_1stateDS.html" title="State-space data source simulating two densities.">bdm::stateDS</a></li>
+</ul>
+<p>The MemDS has already been introduced in the example in <a class="el" href="user_guide.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>
 <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>
 <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>
@@ -247,5 +247,5 @@
 <ul>
 <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>
-<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>
+<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>
 <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>
 <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>
@@ -272,5 +272,5 @@
 mxDS.drv     = drv;
 </pre></div> </div>
-<hr size="1"/><address style="text-align: right;"><small>Generated on Mon Oct 12 19:37:19 2009 for mixpp by&nbsp;
+<hr size="1"/><address style="text-align: right;"><small>Generated on Wed Oct 14 23:00:33 2009 for mixpp by&nbsp;
 <a href="http://www.doxygen.org/index.html">
 <img class="footer" src="doxygen.png" alt="doxygen"/></a> 1.6.1 </small></address>
