Xcos help: simplify the HTML characters 55/13055/2
Paul BIGNIER [Thu, 31 Oct 2013 11:55:22 +0000 (12:55 +0100)]
Change-Id: Ie57f41ae405fe1c092fb2dae65643e53ef3d3eb9

28 files changed:
scilab/modules/xcos/help/en_US/batch_functions/lincos.xml
scilab/modules/xcos/help/en_US/batch_functions/steadycos.xml
scilab/modules/xcos/help/en_US/palettes/Electrical_pal/NPN.xml
scilab/modules/xcos/help/en_US/palettes/Electrical_pal/PNP.xml
scilab/modules/xcos/help/en_US/palettes/Mathoperations_pal/MATMAGPHI.xml
scilab/modules/xcos/help/en_US/palettes/Mathoperations_pal/MATZREIM.xml
scilab/modules/xcos/help/en_US/palettes/Matrix_pal/MATSING.xml
scilab/modules/xcos/help/en_US/programming_scicos_blocks/c_computational_functions/C_struct.xml
scilab/modules/xcos/help/en_US/programming_scicos_blocks/utilities_functions/getscicosvars.xml
scilab/modules/xcos/help/en_US/solvers/0-LSodar.xml
scilab/modules/xcos/help/en_US/solvers/1-CVode.xml
scilab/modules/xcos/help/en_US/solvers/3-Dormand-Prince.xml
scilab/modules/xcos/help/en_US/solvers/4-ImplicitRK.xml
scilab/modules/xcos/help/en_US/solvers/6-IDA.xml
scilab/modules/xcos/help/en_US/solvers/7-DDaskr.xml
scilab/modules/xcos/help/en_US/solvers/8-Rootfinding.xml
scilab/modules/xcos/help/fr_FR/palettes/Electrical_pal/NPN.xml
scilab/modules/xcos/help/fr_FR/palettes/Electrical_pal/PNP.xml
scilab/modules/xcos/help/fr_FR/palettes/Mathoperations_pal/MATMAGPHI.xml
scilab/modules/xcos/help/fr_FR/palettes/Mathoperations_pal/MATZREIM.xml
scilab/modules/xcos/help/fr_FR/palettes/Matrix_pal/MATSING.xml
scilab/modules/xcos/help/fr_FR/solvers/0-LSodar.xml
scilab/modules/xcos/help/fr_FR/solvers/1-CVode.xml
scilab/modules/xcos/help/fr_FR/solvers/3-Dormand-Prince.xml
scilab/modules/xcos/help/fr_FR/solvers/4-RKImplicite.xml
scilab/modules/xcos/help/fr_FR/solvers/6-IDA.xml
scilab/modules/xcos/help/fr_FR/solvers/7-DDaskr.xml
scilab/modules/xcos/help/fr_FR/solvers/8-Racines.xml

index 8f1d49d..1eda1ca 100644 (file)
@@ -1,24 +1,24 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <!--
  * Scicos
- * 
+ *
  * Copyright (C) INRIA - METALAU Project <scicos@inria.fr> (HTML version)
  * Copyright (C) DIGITEO - Scilab Consortium (XML Docbook version)
- * 
+ *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
  * the Free Software Foundation; either version 2 of the License, or
  *  (at your option) any later version.
- * 
+ *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
- * 
+ *
  * You should have received a copy of the GNU General Public License
  * along with this program; if not, write to the Free Software
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
- * 
+ *
  * See the file ./license.txt
  -->
 <refentry xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:svg="http://www.w3.org/2000/svg" xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:db="http://docbook.org/ns/docbook" xmlns:scilab="http://www.scilab.org" xml:id="lincos">
index c3ee1fc..31c7804 100644 (file)
@@ -1,24 +1,24 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <!--
  * Scicos
- * 
+ *
  * Copyright (C) INRIA - METALAU Project <scicos@inria.fr> (HTML version)
  * Copyright (C) DIGITEO - Scilab Consortium (XML Docbook version)
- * 
+ *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
  * the Free Software Foundation; either version 2 of the License, or
  *  (at your option) any later version.
- * 
+ *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
- * 
+ *
  * You should have received a copy of the GNU General Public License
  * along with this program; if not, write to the Free Software
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
- * 
+ *
  * See the file ./license.txt
  -->
 <refentry xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:svg="http://www.w3.org/2000/svg" xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:db="http://docbook.org/ns/docbook" xmlns:scilab="http://www.scilab.org" xml:id="steadycos">
@@ -43,7 +43,7 @@
     <refsection id="Description_steadycos">
         <title>Description</title>
         <para>
-            This function finds the steady state for a given system described by a xcos diagram or <link linkend="SUPER_f">sub-diagram</link>. The diagram should have <link linkend="IN_f">inputs</link> and <link linkend="OUT_f">outputs</link>.The steady state concern only the continuous-time dynamics.  
+            This function finds the steady state for a given system described by a xcos diagram or <link linkend="SUPER_f">sub-diagram</link>. The diagram should have <link linkend="IN_f">inputs</link> and <link linkend="OUT_f">outputs</link>.The steady state concern only the continuous-time dynamics.
         </para>
     </refsection>
     <refsection>
index cd85ff0..293baa9 100644 (file)
@@ -1,24 +1,24 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <!--
  * Scicos
- * 
+ *
  * Copyright (C) INRIA - METALAU Project <scicos@inria.fr> (HTML version)
  * Copyright (C) DIGITEO - Scilab Consortium (XML Docbook version)
- * 
+ *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
  * the Free Software Foundation; either version 2 of the License, or
  *  (at your option) any later version.
- * 
+ *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
- * 
+ *
  * You should have received a copy of the GNU General Public License
  * along with this program; if not, write to the Free Software
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
- * 
+ *
  * See the file ./license.txt
  -->
 <refentry xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:svg="http://www.w3.org/2000/svg" xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:db="http://docbook.org/ns/docbook" xmlns:scilab="http://www.scilab.org" xml:id="NPN">
@@ -98,7 +98,7 @@
     <refsection id="Description_NPN">
         <title>Description</title>
         <para>
-            This model is a simple model of a bipolar NPN junction transistor according to Ebers-Moll.  
+            This model is a simple model of a bipolar NPN junction transistor according to Ebers-Moll.
         </para>
         <para>
         </para>
             <tr>
                 <td align="left">EMax</td>
                 <td align="left">40</td>
-                <td align="left">if x &gt; EMax, the exp(x) function is linearized</td>
+                <td align="left">if x > EMax, the exp(x) function is linearized</td>
             </tr>
         </informaltable>
     </refsection>
index a00258a..6ffba35 100644 (file)
@@ -1,24 +1,24 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <!--
  * Scicos
- * 
+ *
  * Copyright (C) INRIA - METALAU Project <scicos@inria.fr> (HTML version)
  * Copyright (C) DIGITEO - Scilab Consortium (XML Docbook version)
- * 
+ *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
  * the Free Software Foundation; either version 2 of the License, or
  *  (at your option) any later version.
- * 
+ *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
- * 
+ *
  * You should have received a copy of the GNU General Public License
  * along with this program; if not, write to the Free Software
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
- * 
+ *
  * See the file ./license.txt
  -->
 <refentry xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:svg="http://www.w3.org/2000/svg" xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:db="http://docbook.org/ns/docbook" xmlns:scilab="http://www.scilab.org" xml:id="PNP">
@@ -98,7 +98,7 @@
     <refsection id="Description_PNP">
         <title>Description</title>
         <para>
-            This model is a simple model of a bipolar PNP junction transistor according to Ebers-Moll.  
+            This model is a simple model of a bipolar PNP junction transistor according to Ebers-Moll.
         </para>
         <para>
         </para>
             <tr>
                 <td align="left">EMax</td>
                 <td align="left">40</td>
-                <td align="left">if x &gt; EMax, the exp(x) function is linearized</td>
+                <td align="left">if x > EMax, the exp(x) function is linearized</td>
             </tr>
         </informaltable>
     </refsection>
index f304b67..6634ef4 100644 (file)
         <itemizedlist>
             <listitem>
                 <para>
-                    <emphasis role="bold">Decomposition type (1=Complex2MAG&amp;amp;PHI 2=MAG&amp;amp;PHI2Complex)</emphasis>
+                    <emphasis role="bold">Decomposition type (1=Complex2MAG&amp;PHI 2=MAG&amp;PHI2Complex)</emphasis>
                 </para>
                 <para>It indicates the rule of the conversion.</para>
                 <para>Properties : Type 'vec' of size 1.</para>
index 21e11dc..54e61e8 100644 (file)
         <itemizedlist>
             <listitem>
                 <para>
-                    <emphasis role="bold">Decomposition type (1=Complex2Real&amp;amp;Imag 2=Real&amp;amp;Imag2Complex)</emphasis>
+                    <emphasis role="bold">Decomposition type (1=Complex2Real&amp;Imag 2=Real&amp;Imag2Complex)</emphasis>
                 </para>
                 <para> Indicates the type to use for the decomposition. See the description part for more information.</para>
                 <para> Properties : Type 'vec' of size 1.</para>
index d456951..4eb9879 100644 (file)
             <listitem>
                 <para>
                     <emphasis role="bold">decomposition type (1=singular values 2=sing
-                        values+matrix U &amp;amp; V)
+                        values+matrix U &amp; V)
                     </emphasis>
                 </para>
                 <para>
index 4af4709..c42f6e0 100644 (file)
         <itemizedlist>
             <listitem>
                 <para>
-                    <emphasis role="bold">block-&gt;nin :</emphasis> Integer that gives the number of regular input ports of the block.
+                    <emphasis role="bold">block->nin :</emphasis> Integer that gives the number of regular input ports of the block.
                 </para>
                 <para>
-                    One can't override the index <literal>(3*block-&gt;nin)-1</literal> when reading sizes of input ports in the array <literal>insz</literal> and the index <literal>block-&gt;nin-1</literal> when reading data in the array <literal>inptr</literal> with a C computational function.
+                    One can't override the index <literal>(3*block->nin)-1</literal> when reading sizes of input ports in the array <literal>insz</literal> and the index <literal>block->nin-1</literal> when reading data in the array <literal>inptr</literal> with a C computational function.
                     The number of regular input ports can also be got by the use of the C macros <literal>GetNin(block)</literal>. 
                 </para>
             </listitem>
             <listitem>
                 <para>
-                    <emphasis role="bold">block-&gt;insz :</emphasis> An array of integers of size <literal>(3*block-&gt;nin)-1</literal> that respectively gives the first dimensions, the second dimensions and the type of data driven by regular input ports.
+                    <emphasis role="bold">block->insz :</emphasis> An array of integers of size <literal>(3*block->nin)-1</literal> that respectively gives the first dimensions, the second dimensions and the type of data driven by regular input ports.
                 </para>
                 <para>
-                     Note that this array of size differs from the array <literal>ozsz</literal> and <literal>oparsz</literal> to provide full compatibility with blocks that only use a single dimension.
+                    Note that this array of size differs from the array <literal>ozsz</literal> and <literal>oparsz</literal> to provide full compatibility with blocks that only use a single dimension.
                 </para>
                 <para>Suppose that you have a block with three inputs : the first is an int32 matrix of size [3,2], the second a single complex number (matrix of size [1,1]) and the last a real matrix of size [4,1].</para>
                 <para>
                     model.intyp = [2;1;3];
                 </programlisting>
                 <para>
-                    and the corresponding <literal>block-&gt;insz</literal> field at C computational function level will be coded as :
+                    and the corresponding <literal>block->insz</literal> field at C computational function level will be coded as :
                 </para>
                 <mediaobject>
                     <imageobject>
@@ -232,11 +232,11 @@ boxht=Dim1start.ht * 0.5;
             </listitem>
             <listitem>
                 <para>
-                    <emphasis role="bold">block-&gt;inptr :</emphasis> An array of pointers of size nin,1 that allow to directly access to the data contained in the regular input matrices.
+                    <emphasis role="bold">block->inptr :</emphasis> An array of pointers of size nin,1 that allow to directly access to the data contained in the regular input matrices.
                 </para>
                 <para>Suppose the previous example (block with three inputs : an int32 matrix of size [3,2], a complex scalar and a real matrix of size [4,1]).</para>
                 <para>
-                    <literal>block-&gt;inptr</literal> contains three pointers, and should be viewed as arrays contained the data for the int32, the real and the complex matrices :
+                    <literal>block->inptr</literal> contains three pointers, and should be viewed as arrays contained the data for the int32, the real and the complex matrices :
                 </para>
                 <mediaobject>
                     <imageobject>
@@ -364,18 +364,18 @@ void mycomputfunc(scicos_block *block,int flag)
             </listitem>
             <listitem>
                 <para>
-                    <emphasis role="bold">block-&gt;nout :</emphasis> Integer that gives the number of regular output ports of the block.
+                    <emphasis role="bold">block->nout :</emphasis> Integer that gives the number of regular output ports of the block.
                 </para>
                 <para>
-                    One can't override the index <literal>(3*block-&gt;nout)-1</literal> when reading sizes of output ports in the array <literal>outsz</literal> and the index <literal>block-&gt;nout-1</literal> when reading data in the array <literal>outptr</literal>with a C computational function.
+                    One can't override the index <literal>(3*block->nout)-1</literal> when reading sizes of output ports in the array <literal>outsz</literal> and the index <literal>block->nout-1</literal> when reading data in the array <literal>outptr</literal>with a C computational function.
                 </para>
                 <para>
-                     The number of regular output ports can also be got by the use of the C macros <literal>GetNout(block)</literal> . 
+                    The number of regular output ports can also be got by the use of the C macros <literal>GetNout(block)</literal> . 
                 </para>
             </listitem>
             <listitem>
                 <para>
-                    <emphasis role="bold">block-&gt;outsz :</emphasis> An array of integers of size <literal>(3*block-&gt;nout)-1</literal> that respectively gives the first dimensions, the second dimensions and the type of data driven by regular output ports.
+                    <emphasis role="bold">block->outsz :</emphasis> An array of integers of size <literal>(3*block->nout)-1</literal> that respectively gives the first dimensions, the second dimensions and the type of data driven by regular output ports.
                 </para>
                 <para>
                     Note that this array of size differs from the array <literal>ozsz</literal> and <literal>oparsz</literal> to provide full compatibility with blocks that only use a single dimension.
@@ -391,7 +391,7 @@ model.out2 = [2;1;1];
 model.outtyp = [2;1;3];
                      ]]></programlisting>
                 <para>
-                    and the corresponding <literal>block-&gt;outsz</literal> field at C computational function level will be coded as :
+                    and the corresponding <literal>block->outsz</literal> field at C computational function level will be coded as :
                 </para>
                 <mediaobject>
                     <imageobject>
@@ -424,11 +424,11 @@ boxht=Dim1start.ht * 0.5;
             </listitem>
             <listitem>
                 <para>
-                    <emphasis role="bold">block-&gt;outptr :</emphasis> An array of pointers of size [nout,1] that allow to directly acces to the data contained in the regular output matrices.
+                    <emphasis role="bold">block->outptr :</emphasis> An array of pointers of size [nout,1] that allow to directly acces to the data contained in the regular output matrices.
                 </para>
                 <para> Suppose the previous example (block with three outputs : an int32 matrix of size [3,2], a complex scalar and a real matrix of size [4,1]).</para>
                 <para>
-                    <literal>block-&gt;outptr</literal> contains three pointers, and should be viewed as arrays contained the data for the int32, the real and the complex matrices :
+                    <literal>block->outptr</literal> contains three pointers, and should be viewed as arrays contained the data for the int32, the real and the complex matrices :
                 </para>
                 <mediaobject>
                     <imageobject>
@@ -553,29 +553,29 @@ void mycomputfunc(scicos_block *block,int flag)
         <itemizedlist>
             <listitem>
                 <para>
-                    <emphasis role="bold">block-&gt;nevprt :</emphasis> Integer that gives the event input port number by which the block has been activated. This number is a binary coding. For i.e, if block has two event inputs ports, <literal> block-&gt;nevptr</literal>can take the value <literal>1</literal> if the block has been called by its first event input port, the value <literal>2</literal> if it has been called by the second event input port and <literal>3</literal> if it is called by the same event on both input port 1 and 2.
+                    <emphasis role="bold">block->nevprt :</emphasis> Integer that gives the event input port number by which the block has been activated. This number is a binary coding. For i.e, if block has two event inputs ports, <literal> block->nevptr</literal>can take the value <literal>1</literal> if the block has been called by its first event input port, the value <literal>2</literal> if it has been called by the second event input port and <literal>3</literal> if it is called by the same event on both input port 1 and 2.
                 </para>
                 <para>
-                     Note that can be <literal>-1</literal> if the block is internally called.
+                    Note that can be <literal>-1</literal> if the block is internally called.
                 </para>
                 <para>
-                     One can also retrieve this number by using the C macros <literal>GetNevIn(block)</literal>
+                    One can also retrieve this number by using the C macros <literal>GetNevIn(block)</literal>
                 </para>
             </listitem>
             <listitem>
                 <para>
-                    <emphasis role="bold">block-&gt;nevout :</emphasis> Integer that gives the number of event output ports of the block (also called the length of the output event register).
+                    <emphasis role="bold">block->nevout :</emphasis> Integer that gives the number of event output ports of the block (also called the length of the output event register).
                 </para>
                 <para>
-                     One can't override the index <literal>block-&gt;nevout-1</literal> when setting value of events in the output event register <literal>evout</literal>.
+                    One can't override the index <literal>block->nevout-1</literal> when setting value of events in the output event register <literal>evout</literal>.
                 </para>
                 <para>
-                     The number of event output ports can also be got by the use of the C macro <literal>GetNevOut(block)</literal>. 
+                    The number of event output ports can also be got by the use of the C macro <literal>GetNevOut(block)</literal>. 
                 </para>
             </listitem>
             <listitem>
                 <para>
-                    <emphasis role="bold">block-&gt;evout :</emphasis> Array of double of size [nevout,1] corresponding to the output event register. That register is used to program date of events during the simulation.
+                    <emphasis role="bold">block->evout :</emphasis> Array of double of size [nevout,1] corresponding to the output event register. That register is used to program date of events during the simulation.
                 </para>
                 <para> When setting values in that array, you must understand that you give a delay relative to the current time of simulator :</para>
                 <latex>
@@ -607,7 +607,7 @@ void mycomputfunc(scicos_block *block,int flag)
 ]]></programlisting>
                 <para> 
                     Note that every events generated from output event register will be asynchronous with event coming from event input port (even if you set 
-                    <literal>block-&gt;evout[x]=0</literal>). 
+                    <literal>block->evout[x]=0</literal>). 
                 </para>
                 <para>
                     The event output register must be only written for 
@@ -627,18 +627,18 @@ void mycomputfunc(scicos_block *block,int flag)
         <itemizedlist>
             <listitem>
                 <para>
-                    <emphasis role="bold">block-&gt;nrpar :</emphasis> Integer that gives the length of the real parameter register.
+                    <emphasis role="bold">block->nrpar :</emphasis> Integer that gives the length of the real parameter register.
                 </para>
                 <para>
-                     One can't override the index <literal>(block-&gt;nrpar)-1</literal> when reading value of real parameters in the register <literal>rpar</literal>.
+                    One can't override the index <literal>(block->nrpar)-1</literal> when reading value of real parameters in the register <literal>rpar</literal>.
                 </para>
                 <para>
-                     The total number of real parameters can also be got by the use of the C macro <literal>rpar</literal>. 
+                    The total number of real parameters can also be got by the use of the C macro <literal>rpar</literal>. 
                 </para>
             </listitem>
             <listitem>
                 <para>
-                    <emphasis role="bold">block-&gt;rpar :</emphasis> Array of double of size [nrpar,1] corresponding to the real parameter register. That register is used to pass real parameters coming from the Scilab/Xcos environment to your block model.
+                    <emphasis role="bold">block->rpar :</emphasis> Array of double of size [nrpar,1] corresponding to the real parameter register. That register is used to pass real parameters coming from the Scilab/Xcos environment to your block model.
                 </para>
                 <para> The C type of that array is (or C scicos type ).</para>
                 <para>
@@ -712,7 +712,7 @@ void mycomputfunc(scicos_block *block,int flag)
     /*get the A ptrs array*/
     A = rpar;
     /*get the B ptrs array*/
-    B = &rpar[4];
+    B = &amp;rpar[4];
     /*or B = rpar + 4;*/
 ...
 }
@@ -723,18 +723,18 @@ void mycomputfunc(scicos_block *block,int flag)
             </listitem>
             <listitem>
                 <para>
-                    <emphasis role="bold">block-&gt;nipar :</emphasis> Integer that gives the length of the integer parameter register.
+                    <emphasis role="bold">block->nipar :</emphasis> Integer that gives the length of the integer parameter register.
                 </para>
                 <para>
-                     One can't override the index <literal>(block-&gt;nipar)-1</literal> when reading value of integer parameters in the register <literal>ipar</literal>.
+                    One can't override the index <literal>(block->nipar)-1</literal> when reading value of integer parameters in the register <literal>ipar</literal>.
                 </para>
                 <para>
-                     The total number of integer parameters can also be got by the use of the C macro <literal>GetNipar(block)</literal>. 
+                    The total number of integer parameters can also be got by the use of the C macro <literal>GetNipar(block)</literal>. 
                 </para>
             </listitem>
             <listitem>
                 <para>
-                    <emphasis role="bold">block-&gt;ipar :</emphasis> Array of int of size nipar,1 corresponding to the integer parameter register. That register is used to pass integer parameters coming from the Scilab/Xcos environment to your block model.
+                    <emphasis role="bold">block->ipar :</emphasis> Array of int of size nipar,1 corresponding to the integer parameter register. That register is used to pass integer parameters coming from the Scilab/Xcos environment to your block model.
                 </para>
                 <para>
                     The C type of that array is <literal>int*</literal> (or C scicos type <literal>SCSINT_COP *</literal>).
@@ -825,7 +825,7 @@ void mycomputfunc(scicos_block *block,int flag)
     /*get the A ptrs array*/
     A = rpar;
     /*get the B ptrs array*/
-    B = &rpar[A_sz];
+    B = &amp;rpar[A_sz];
 
     /*compute the cumsum of the first real parameter array*/
     cumsum = 0;
@@ -847,18 +847,18 @@ void mycomputfunc(scicos_block *block,int flag)
             </listitem>
             <listitem>
                 <para>
-                    <emphasis role="bold">block-&gt;nopar :</emphasis> Integer that gives the number of the object parameters.
+                    <emphasis role="bold">block->nopar :</emphasis> Integer that gives the number of the object parameters.
                 </para>
                 <para>
-                     One can't override the index <literal>block-&gt;nopar-1</literal> when accessing data in the arrays <literal>oparsz</literal>, <literal>opartyp</literal>and <literal>oparptr</literal> in a C computational function.
+                    One can't override the index <literal>block->nopar-1</literal> when accessing data in the arrays <literal>oparsz</literal>, <literal>opartyp</literal>and <literal>oparptr</literal> in a C computational function.
                 </para>
                 <para>
-                     This value is also accessible via the C macro <literal>GetNopar(block)</literal>.
+                    This value is also accessible via the C macro <literal>GetNopar(block)</literal>.
                 </para>
             </listitem>
             <listitem>
                 <para>
-                    <emphasis role="bold">block-&gt;oparsz :</emphasis> An array of integer of size [nopar,2] that contains the dimensions of matrices of object parameters.
+                    <emphasis role="bold">block->oparsz :</emphasis> An array of integer of size [nopar,2] that contains the dimensions of matrices of object parameters.
                 </para>
                 <para> The first column is for the first dimension and the second for the second dimension. For i.e. if we want the dimensions of the last object parameters, we'll use the instructions :
                 </para>
@@ -889,10 +889,10 @@ void mycomputfunc(scicos_block *block,int flag)
             </listitem>
             <listitem>
                 <para>
-                    <emphasis role="bold">block-&gt;opartyp :</emphasis> An array of integer of size [nopar,1] that contains the type of matrices of object parameters.
+                    <emphasis role="bold">block->opartyp :</emphasis> An array of integer of size [nopar,1] that contains the type of matrices of object parameters.
                 </para>
                 <para>
-                     The following table gives the correspondence for Scicos/Xcos type expressed in Scilab number, in C number and also corresponding C pointers and C macros used for <literal>oparptr</literal>:
+                    The following table gives the correspondence for Scicos/Xcos type expressed in Scilab number, in C number and also corresponding C pointers and C macros used for <literal>oparptr</literal>:
                 </para>
                 <informaltable>
                     <tr>
@@ -953,7 +953,7 @@ void mycomputfunc(scicos_block *block,int flag)
             </listitem>
             <listitem>
                 <para>
-                    <emphasis role="bold">block-&gt;oparptr :</emphasis> An array of pointers of size [nopar,1] that allow to a direct access to the data contained in the object parameter.
+                    <emphasis role="bold">block->oparptr :</emphasis> An array of pointers of size [nopar,1] that allow to a direct access to the data contained in the object parameter.
                 </para>
                 <para>
                     Suppose that you have defined in the editor a block with the following<emphasis role="bold">opar</emphasis> field in<link linkend="scicos_model">scicos_model</link> :
@@ -969,10 +969,10 @@ model.opar=list( ..
                     Then we have three object parameters, one is an 32-bit integer matrix with two rows and two columns, the second is a vector of complex numbers that can be understand as a matrix of size [1,3] and the third is a string encoded as a standard C one (ASCII ended with a '\0').
                 </para>
                 <para>
-                    At the C computational function level, the instructions <literal>block-&gt;oparsz[0]</literal>, <literal>block-&gt;oparsz[1]</literal>, <literal>block-&gt;oparsz[2]</literal>, <literal>block-&gt;oparsz[3]</literal>, <literal>block-&gt;oparsz[4]</literal>, <literal>block-&gt;oparsz[5]</literal> will respectively return the values <literal>2, 1, 1, 2, 3, 3</literal> and the instructions <literal>block-&gt;opartyp[0]</literal>, <literal>block-&gt;opartyp[1]</literal>, <literal>block-&gt;opartyp[2]</literal> the values <literal>11, 84, 81</literal>.
+                    At the C computational function level, the instructions <literal>block->oparsz[0]</literal>, <literal>block->oparsz[1]</literal>, <literal>block->oparsz[2]</literal>, <literal>block->oparsz[3]</literal>, <literal>block->oparsz[4]</literal>, <literal>block->oparsz[5]</literal> will respectively return the values <literal>2, 1, 1, 2, 3, 3</literal> and the instructions <literal>block->opartyp[0]</literal>, <literal>block->opartyp[1]</literal>, <literal>block->opartyp[2]</literal> the values <literal>11, 84, 81</literal>.
                 </para>
                 <para>
-                    <literal>block-&gt;oparptr</literal> will contain then three pointers, and should be viewed as arrays contained data of object parameter as shown in the following figure :
+                    <literal>block->oparptr</literal> will contain then three pointers, and should be viewed as arrays contained data of object parameter as shown in the following figure :
                 </para>
                 <mediaobject>
                     <imageobject>
@@ -1095,15 +1095,15 @@ void mycomputfunc(scicos_block *block,int flag)
         <itemizedlist>
             <listitem>
                 <para>
-                    <emphasis role="bold">block-&gt;nx :</emphasis> Integer that gives the length of the continus state register.
+                    <emphasis role="bold">block->nx :</emphasis> Integer that gives the length of the continus state register.
                 </para>
                 <para>
-                     One can't override the index <literal>block-&gt;nx-1</literal> when reading or writing data in the array , or with a C computational function. 
+                    One can't override the index <literal>block->nx-1</literal> when reading or writing data in the array , or with a C computational function. 
                 </para>
             </listitem>
             <listitem>
                 <para>
-                    <emphasis role="bold">block-&gt;x :</emphasis> Array of double of size [nx,1] corresponding to the continuous state register.
+                    <emphasis role="bold">block->x :</emphasis> Array of double of size [nx,1] corresponding to the continuous state register.
                 </para>
                 <para> That gives the result of the computation of the state derivative.</para>
                 <para> A value of a continuous state is readable (for i.e the first state) with the C instructions :
@@ -1131,13 +1131,13 @@ void mycomputfunc(scicos_block *block,int flag)
             </listitem>
             <listitem>
                 <para>
-                    <emphasis role="bold">block-&gt;xd :</emphasis> Array of double of size [nx,1] corresponding to the derivative of the continuous state register.
+                    <emphasis role="bold">block->xd :</emphasis> Array of double of size [nx,1] corresponding to the derivative of the continuous state register.
                 </para>
                 <para>
                     When systems are explicitly given in terms of Ordinary Differential Equations (ODE), it can be explicitly expressed or implicitly used in the residual vector <literal>res</literal> when systems are expressed in terms of Differantial Algebraic Equations (DAE).
                 </para>
                 <para>
-                     Both systems must be programmed with <literal>flag=0</literal>.
+                    Both systems must be programmed with <literal>flag=0</literal>.
                 </para>
                 <para>For i.e the Lorenz attractor written as an ODE system with three state variables, of the form :
                 </para>
@@ -1176,7 +1176,7 @@ void mycomputfunc(scicos_block *block,int flag)
             </listitem>
             <listitem>
                 <para>
-                    <emphasis role="bold">block-&gt;res :</emphasis> Array of double of size [nx,1] corresponding to Differential Algebraic Equation (DAE) residual.
+                    <emphasis role="bold">block->res :</emphasis> Array of double of size [nx,1] corresponding to Differential Algebraic Equation (DAE) residual.
                 </para>
                 <para> It is used to write the vector of systems that have the following form :</para>
                 <latex>
@@ -1214,18 +1214,18 @@ void mycomputfunc(scicos_block *block,int flag)
             </listitem>
             <listitem>
                 <para>
-                    <emphasis role="bold">block-&gt;nz :</emphasis> Integer that gives the length of the discrete state register.
+                    <emphasis role="bold">block->nz :</emphasis> Integer that gives the length of the discrete state register.
                 </para>
                 <para>
-                     One can't override the index <literal>block-&gt;nz-1</literal> when reading data in the array <literal>z</literal> with a C computational function.
+                    One can't override the index <literal>block->nz-1</literal> when reading data in the array <literal>z</literal> with a C computational function.
                 </para>
                 <para>
-                     This value is also accessible via the C macros <literal>GetNdstate(block)</literal>. 
+                    This value is also accessible via the C macros <literal>GetNdstate(block)</literal>. 
                 </para>
             </listitem>
             <listitem>
                 <para>
-                    <emphasis role="bold">block-&gt;z :</emphasis> Array of double of size [nz,1] corresponding to the discrete state register.
+                    <emphasis role="bold">block->z :</emphasis> Array of double of size [nz,1] corresponding to the discrete state register.
                 </para>
                 <para>A value of a discrete state is directly readable (for i.e the second state) with the C instructions :
                 </para>
@@ -1252,10 +1252,10 @@ void mycomputfunc(scicos_block *block,int flag)
             </listitem>
             <listitem>
                 <para>
-                    <emphasis role="bold">block-&gt;noz :</emphasis> Integer that gives the number of the discrete object states.
+                    <emphasis role="bold">block->noz :</emphasis> Integer that gives the number of the discrete object states.
                 </para>
                 <para>
-                    One can't override the index <literal>block-&gt;noz-1</literal> when accessing data in the arrays <literal>ozsz</literal>, <literal>oztyp</literal> and <literal>ozptr</literal> in a C computational function.
+                    One can't override the index <literal>block->noz-1</literal> when accessing data in the arrays <literal>ozsz</literal>, <literal>oztyp</literal> and <literal>ozptr</literal> in a C computational function.
                 </para>
                 <para>
                     This value is also accessible via the C macro <literal>GetNoz(block)</literal>. 
@@ -1263,7 +1263,7 @@ void mycomputfunc(scicos_block *block,int flag)
             </listitem>
             <listitem>
                 <para>
-                    <emphasis role="bold">block-&gt;ozsz :</emphasis> An array of integer of size [noz,2] that contains the dimensions of matrices of discrete object states.
+                    <emphasis role="bold">block->ozsz :</emphasis> An array of integer of size [noz,2] that contains the dimensions of matrices of discrete object states.
                 </para>
                 <para> The first column is for the first dimension and the second for the second dimension. For i.e. if we want the dimensions of the last object state, we'll use the instructions :
                 </para>
@@ -1293,10 +1293,10 @@ void mycomputfunc(scicos_block *block,int flag)
             </listitem>
             <listitem>
                 <para>
-                    <emphasis role="bold">block-&gt;oztyp :</emphasis> An array of integer of size [noz,1] that contains the type of matrices of discrete object states.
+                    <emphasis role="bold">block->oztyp :</emphasis> An array of integer of size [noz,1] that contains the type of matrices of discrete object states.
                 </para>
                 <para>
-                     The following table gives the correspondence table for scicos type expressed in Scilab number, in C number and also corresponding C pointers and C macros used for <literal>ozptr</literal>:
+                    The following table gives the correspondence table for scicos type expressed in Scilab number, in C number and also corresponding C pointers and C macros used for <literal>ozptr</literal>:
                 </para>
                 <informaltable>
                     <tr>
@@ -1354,7 +1354,7 @@ void mycomputfunc(scicos_block *block,int flag)
             </listitem>
             <listitem>
                 <para>
-                    <emphasis role="bold">block-&gt;ozptr :</emphasis> An array of pointers of size [noz,1] that allow to a direct access to the data contained in the discrete object state.
+                    <emphasis role="bold">block->ozptr :</emphasis> An array of pointers of size [noz,1] that allow to a direct access to the data contained in the discrete object state.
                 </para>
                 <para>
                     Suppose that you have defined in the editor a block with the following<emphasis role="bold">odstate</emphasis> field in <link linkend="scicos_model">scicos_model</link> :
@@ -1367,10 +1367,10 @@ model.odstate=list(int32([1,2;3,4]),[1+%i %i 0.5]);
                     Then we have two discrete object states, one is an 32-bit integer matrix with two rows and two columns and the second is a vector of complex numbers that can be understand as a matrix of size [1,3].
                 </para>
                 <para>
-                    At the C computational function level, the instructions <literal>block-&gt;ozsz[0]</literal>, <literal>block-&gt;ozsz[1]</literal>, <literal>block-&gt;ozsz[2]</literal> and <literal>block-&gt;ozsz[3]</literal> will respectively return the values <literal>2,1,2,3</literal> and the instructions <literal>block-&gt;oztyp[0]</literal>, <literal>block-&gt;oztyp[1]</literal> the values <literal>11</literal> and <literal>84</literal>.
+                    At the C computational function level, the instructions <literal>block->ozsz[0]</literal>, <literal>block->ozsz[1]</literal>, <literal>block->ozsz[2]</literal> and <literal>block->ozsz[3]</literal> will respectively return the values <literal>2,1,2,3</literal> and the instructions <literal>block->oztyp[0]</literal>, <literal>block->oztyp[1]</literal> the values <literal>11</literal> and <literal>84</literal>.
                 </para>
                 <para>
-                     <literal>block-&gt;ozptr</literal> will then contain two pointers, and should be viewed as arrays contained data of discrete object state as shown in the following figure :
+                    <literal>block->ozptr</literal> will then contain two pointers, and should be viewed as arrays contained data of discrete object state as shown in the following figure :
                 </para>
                 <mediaobject>
                     <imageobject>
@@ -1469,7 +1469,7 @@ void mycomputfunc(scicos_block *block,int flag)
             </listitem>
             <listitem>
                 <para>
-                    <emphasis role="bold">block-&gt;work :</emphasis> A free pointer to set a working array for the block.
+                    <emphasis role="bold">block->work :</emphasis> A free pointer to set a working array for the block.
                 </para>
                 <para>
                     The work pointer must be firstly allocated when <literal>flag=4</literal> and finally be free in the <literal>flag=5</literal>.
@@ -1526,10 +1526,10 @@ void mycomputfunc(scicos_block *block,int flag)
         <itemizedlist>
             <listitem>
                 <para>
-                    <emphasis role="bold">block-&gt;ng :</emphasis> Integer that gives the number of zero crossing surface of the block.
+                    <emphasis role="bold">block->ng :</emphasis> Integer that gives the number of zero crossing surface of the block.
                 </para>
                 <para>
-                     One can't override the index <literal>(block-&gt;ng)-1</literal> when reading/writing data in the array <literal>g</literal> with a C computational function.
+                    One can't override the index <literal>(block->ng)-1</literal> when reading/writing data in the array <literal>g</literal> with a C computational function.
                 </para>
                 <para>
                     The number of zero crossing surface can also be got by the use of the C macro <literal>GetNg(block)</literal>. 
@@ -1537,7 +1537,7 @@ void mycomputfunc(scicos_block *block,int flag)
             </listitem>
             <listitem>
                 <para>
-                    <emphasis role="bold">block-&gt;g :</emphasis> Array of double of size [ng,1] corresponding to the zero crossing surface register.
+                    <emphasis role="bold">block->g :</emphasis> Array of double of size [ng,1] corresponding to the zero crossing surface register.
                 </para>
                 <para>That register is used to detect zero crossing of state variable during time domain integration.</para>
                 <para>
@@ -1549,18 +1549,18 @@ void mycomputfunc(scicos_block *block,int flag)
             </listitem>
             <listitem>
                 <para>
-                    <emphasis role="bold">block-&gt;nmode :</emphasis> Integer that gives the number of mode of the block.
+                    <emphasis role="bold">block->nmode :</emphasis> Integer that gives the number of mode of the block.
                 </para>
                 <para>
-                    One can't override the index <literal>(block-&gt;mode)-1</literal> when reading/writing data in the array with a C computational function.
+                    One can't override the index <literal>(block->mode)-1</literal> when reading/writing data in the array with a C computational function.
                 </para>
                 <para>
-                     The number of mode can also be got by the use of the C macro <literal>GetNmode(block)</literal>.
+                    The number of mode can also be got by the use of the C macro <literal>GetNmode(block)</literal>.
                 </para>
             </listitem>
             <listitem>
                 <para>
-                    <emphasis role="bold">block-&gt;mode :</emphasis> Array of integer of size [nmode,1] corresponding to the mode register.
+                    <emphasis role="bold">block->mode :</emphasis> Array of integer of size [nmode,1] corresponding to the mode register.
                 </para>
                 <para> That register is used to set the mode of state variable during time domain integration.</para>
                 <para>
@@ -1580,17 +1580,17 @@ void mycomputfunc(scicos_block *block,int flag)
         <itemizedlist>
             <listitem>
                 <para>
-                    <emphasis role="bold">block-&gt;type :</emphasis> Integer that gives the type of the computational function. For C blocks, this number is equal to <literal>4</literal>. 
+                    <emphasis role="bold">block->type :</emphasis> Integer that gives the type of the computational function. For C blocks, this number is equal to <literal>4</literal>. 
                 </para>
             </listitem>
             <listitem>
                 <para>
-                    <emphasis role="bold">block-&gt;label :</emphasis> Strings array that allows to retrieve the label of the block.
+                    <emphasis role="bold">block->label :</emphasis> Strings array that allows to retrieve the label of the block.
                 </para>
             </listitem>
             <listitem>
                 <para>
-                    <emphasis role="bold">block-&gt;uid :</emphasis> Strings array that allows to retrieve the uid of the block.
+                    <emphasis role="bold">block->uid :</emphasis> Strings array that allows to retrieve the uid of the block.
                 </para>
             </listitem>
         </itemizedlist>
index 4fe8ae4..3c167ca 100644 (file)
                     modes.
                 </para>
                 <para>"iz" : get the register that store pointers of
-                    block-&gt;work.
+                    block->work.
                 </para>
                 <para>"izptr" : get the pointers vector of the register that store C
-                    pointers of block-&gt;work.
+                    pointers of block->work.
                 </para>
                 <para>"nblk" : get the number of block.</para>
                 <para>"outtbptr" : get the register that store C pointers of
index 8850d34..7a1ca31 100644 (file)
@@ -145,11 +145,11 @@ Time for Adams / Functional:
             ]]></screen>
         </para>
         <para>
-            These results show that on a nonstiff problem, for the same precision required, <emphasis>LSodar</emphasis> is significantly faster. Other tests prove the proximity of the results. Indeed, we find that the solution difference order between <emphasis>LSodar</emphasis> and <emphasis>CVode</emphasis> is close to the order of the highest tolerance ( 
+            These results show that on a nonstiff problem, for the same precision required, <emphasis>LSodar</emphasis> is significantly faster. Other tests prove the proximity of the results. Indeed, we find that the solution difference order between <emphasis>LSodar</emphasis> and <emphasis>CVode</emphasis> is close to the order of the highest tolerance (
             <emphasis>
                 y<subscript>lsodar</subscript> - y<subscript>cvode</subscript>
             </emphasis>
-            &#8776; <emphasis>max(reltol, abstol)</emphasis> ).
+            ≈ <emphasis>max(reltol, abstol)</emphasis> ).
         </para>
         <para>
             Variable-size step ODE solvers are not appropriate for deterministic real-time applications because the computational overhead of taking a time step varies over the course of an application.
index c1f2e76..1525809 100644 (file)
             </latex>
         </para>
         <para>
-            Starting with 
+            Starting with
             <emphasis>
                 y<subscript>0</subscript>
             </emphasis>
-            , <emphasis>CVode</emphasis> approximates 
+            , <emphasis>CVode</emphasis> approximates
             <emphasis>
                 y<subscript>n+1</subscript>
             </emphasis>
                 \end{eqnarray}
             </latex>
             <para>
-                &#160; with 
+                 with
                 <emphasis>
                     y<subscript>n</subscript>
                 </emphasis>
-                the approximation of 
+                the approximation of
                 <emphasis>
                     y(t<subscript>n</subscript>)
                 </emphasis>
-                , and 
+                , and
                 <emphasis>
                     h<subscript>n</subscript>
                 </emphasis>
@@ -66,7 +66,7 @@
             </para>
         </para>
         <para>
-            These implicit methods are characterized by their respective order <emphasis>q</emphasis>, which indicates the number of intermediate points required to compute 
+            These implicit methods are characterized by their respective order <emphasis>q</emphasis>, which indicates the number of intermediate points required to compute
             <emphasis>
                 y<subscript>n+1</subscript>
             </emphasis>
             </listitem>
         </itemizedlist>
         <para>
-            The coefficients are fixed, uniquely determined by the method type, its order, the history of the step sizes, and the normalization 
+            The coefficients are fixed, uniquely determined by the method type, its order, the history of the step sizes, and the normalization
             <emphasis>
-                &#x3B1;<subscript>n, 0</subscript> = -1
+                α<subscript>n, 0</subscript> = -1
             </emphasis>
             .
         </para>
             This system can be solved by either <emphasis>Functional</emphasis> or <emphasis>Newton</emphasis> iterations, described hereafter.
         </para>
         <para>
-            In both following cases, the initial "predicted" 
+            In both following cases, the initial "predicted"
             <emphasis>
                 y<subscript>n(0)</subscript>
             </emphasis>
         <itemizedlist>
             <para>  </para>
             <listitem>
-                <emphasis role="bold">Functional:</emphasis> this method only involves evaluations of <emphasis>f</emphasis>, it simply computes 
+                <emphasis role="bold">Functional:</emphasis> this method only involves evaluations of <emphasis>f</emphasis>, it simply computes
                 <emphasis>
                     y<subscript>n(0)</subscript>
                 </emphasis>
                 by iterating the formula:
                 <para>
                     <latex>
-                        y_{n(m+1)} = h_n &#x3B2;_{n,0} f(t_n,y_{n(m)}) + a_n
+                        y_{n(m+1)} = h_n β_{n,0} f(t_n,y_{n(m)}) + a_n
                     </latex>
                     <latex scilab:localized="true">
                         where \hspace{2 mm} a_n\equiv \sum_{i>0} (\alpha_{n,i} y_{n-i} + h_n\beta_{n,i}\dot{y}_{n-i})
             </listitem>
         </itemizedlist>
         <para>
-            In both situations, <emphasis>CVode</emphasis> uses the history array to control the local error 
+            In both situations, <emphasis>CVode</emphasis> uses the history array to control the local error
             <emphasis>
                 y<subscript>n(m)</subscript> - y<subscript>n(0)</subscript>
             </emphasis>
-            and recomputes 
+            and recomputes
             <emphasis>
                 h<subscript>n</subscript>
             </emphasis>
index 2cdec40..d32687d 100644 (file)
@@ -38,7 +38,7 @@
             As of now, this method is explicit, so it is not concerned with Newton or Functional iterations, and not advised for stiff problems.
         </para>
         <para>
-            It is an enhancement of the Euler method, which approximates 
+            It is an enhancement of the Euler method, which approximates
             <emphasis>
                 y<subscript>n+1</subscript>
             </emphasis>
             An important difference of <emphasis>Dormand-Prince</emphasis> with the previous methods is that it computes up to the seventh derivative of <emphasis>y</emphasis>, while the others only use linear combinations of <emphasis>y</emphasis> and <emphasis>y'</emphasis>.
         </para>
         <para>
-            Here, the next value is determined by the present value 
+            Here, the next value is determined by the present value
             <emphasis>
                 y<subscript>n</subscript>
             </emphasis>
             plus the weighted average of six increments, where each increment is the product of the size of the interval, <emphasis>h</emphasis>, and an estimated slope specified by the function <emphasis>f(t,y)</emphasis>:
             <itemizedlist>
                 <listitem>
-                    <emphasis>k1</emphasis> is the increment based on the slope at the beginning of the interval, using 
+                    <emphasis>k1</emphasis> is the increment based on the slope at the beginning of the interval, using
                     <emphasis>
                         y<subscript>n</subscript>
                     </emphasis>
             </itemizedlist>
         </para>
         <para>
-            We can see that with the <emphasis>ki</emphasis>, we progress in the derivatives of 
+            We can see that with the <emphasis>ki</emphasis>, we progress in the derivatives of
             <emphasis>
                 y<subscript>n</subscript>
             </emphasis>
-            . In the computation of the <emphasis>ki</emphasis>, we deliberately use coefficients that yield an error in 
+            . In the computation of the <emphasis>ki</emphasis>, we deliberately use coefficients that yield an error in
             <emphasis>
                 O(h<superscript>5</superscript>)
             </emphasis>
             at every step.
         </para>
         <para>
-            So the total error is 
+            So the total error is
             <emphasis>
                 number of steps * O(h<superscript>5</superscript>)
             </emphasis>
-            . And since <emphasis>number of steps = interval size / h</emphasis> by definition, the total error is in 
+            . And since <emphasis>number of steps = interval size / h</emphasis> by definition, the total error is in
             <emphasis>
                 O(h<superscript>4</superscript>)
             </emphasis>
             .
         </para>
         <para>
-            That error analysis baptized the method <emphasis>Dormand-Prince 4(5)</emphasis>: 
+            That error analysis baptized the method <emphasis>Dormand-Prince 4(5)</emphasis>:
             <emphasis>
                 O(h<superscript>5</superscript>)
             </emphasis>
-            per step, 
+            per step,
             <emphasis>
                 O(h<superscript>4</superscript>)
             </emphasis>
             in total.
         </para>
         <para>
-            Althought the solver works fine for <link linkend="Simulatemenu_Menu_entries">max step size</link> up to 
+            Althought the solver works fine for <link linkend="Simulatemenu_Menu_entries">max step size</link> up to
             <emphasis>
                 10<superscript>-3</superscript>
             </emphasis>
-            , rounding errors sometimes come into play as it approaches 
+            , rounding errors sometimes come into play as it approaches
             <emphasis>
                 4*10<superscript>-4</superscript>
             </emphasis>
index 0942737..208bc8c 100644 (file)
             This method being implicit, it can be used on stiff problems.
         </para>
         <para>
-            It is an enhancement of the backward Euler method, which approximates 
+            It is an enhancement of the backward Euler method, which approximates
             <emphasis>
                 y<subscript>n+1</subscript>
             </emphasis>
-            by computing 
+            by computing
             <emphasis>
                 f(t<subscript>n</subscript>+h, y<subscript>n+1</subscript>)
             </emphasis>
             An important difference of <emphasis>implicit Runge-Kutta</emphasis> with the previous methods is that it computes up to the fourth derivative of <emphasis>y</emphasis>, while the others mainly use linear combinations of <emphasis>y</emphasis> and <emphasis>y'</emphasis>.
         </para>
         <para>
-            Here, the next value is determined by the present value 
+            Here, the next value is determined by the present value
             <emphasis>
                 y<subscript>n</subscript>
             </emphasis>
             plus the weighted average of three increments, where each increment is the product of the size of the interval, <emphasis>h</emphasis>, and an estimated slope specified by the function <emphasis>f(t,y)</emphasis>. They are distributed approximately equally on the interval.
             <itemizedlist>
                 <listitem>
-                    <emphasis>k1</emphasis> is the increment based on the slope near the quarter of the interval, using 
+                    <emphasis>k1</emphasis> is the increment based on the slope near the quarter of the interval, using
                     <emphasis>
                         y<subscript>n</subscript>+ a11*h*k1,
                     </emphasis>
                     ,
                 </listitem>
                 <listitem>
-                    <emphasis>k2</emphasis> is the increment based on the slope near the midpoint of the interval, using 
+                    <emphasis>k2</emphasis> is the increment based on the slope near the midpoint of the interval, using
                     <emphasis>
                         y<subscript>n</subscript> + a21*h*k1 + a22*h*k2,
                     </emphasis>
                     ,
                 </listitem>
                 <listitem>
-                    <emphasis>k3</emphasis> is the increment based on the slope near the third quarter of the interval, using 
+                    <emphasis>k3</emphasis> is the increment based on the slope near the third quarter of the interval, using
                     <emphasis>
                         y<subscript>n</subscript> + a31*h*k1 + a32*h*k2 + a33*h*k3.
                     </emphasis>
             We see that the computation of <emphasis>ki</emphasis> requires <emphasis>ki</emphasis>, thus necessitating the use of a nonlinear solver (here, fixed-point iterations).
         </para>
         <para>
-            First, we set 
+            First, we set
             <emphasis>
                 k0 = h * f(t<subscript>n</subscript>, y<subscript>n</subscript>)
             </emphasis>
-            as first guess for all the <emphasis>ki</emphasis>, to get updated <emphasis>ki</emphasis> and a first value for 
+            as first guess for all the <emphasis>ki</emphasis>, to get updated <emphasis>ki</emphasis> and a first value for
             <emphasis>
                 y<subscript>n+1</subscript>
             </emphasis>
             .
         </para>
         <para>
-            Next, we save and recompute 
+            Next, we save and recompute
             <emphasis>
                 y<subscript>n+1</subscript>
             </emphasis>
             with those new <emphasis>ki</emphasis>.
         </para>
         <para>
-            Then, we compare the two 
+            Then, we compare the two
             <emphasis>
                 y<subscript>n+1</subscript>
             </emphasis>
             This process adds a significant computation time to the method, but greatly improves stability.
         </para>
         <para>
-            We can see that with the <emphasis>ki</emphasis>, we progress in the derivatives of 
+            We can see that with the <emphasis>ki</emphasis>, we progress in the derivatives of
             <emphasis>
                 y<subscript>n</subscript>
             </emphasis>
-            . So in <emphasis>k3</emphasis>, we are approximating 
+            . So in <emphasis>k3</emphasis>, we are approximating
             <emphasis>
                 y<superscript>(3)</superscript><subscript>n</subscript>
             </emphasis>
-            , thus making an error in 
+            , thus making an error in
             <emphasis>
                 O(h<superscript>4</superscript>)
             </emphasis>
-            . But choosing the right coefficients in the computation of the <emphasis>ki</emphasis> (notably the 
+            . But choosing the right coefficients in the computation of the <emphasis>ki</emphasis> (notably the
             <emphasis>
                 a<subscript>ij</subscript>
             </emphasis>
-            ) makes us gain an order, thus making a per-step total error in 
+            ) makes us gain an order, thus making a per-step total error in
             <emphasis>
                 O(h<superscript>5</superscript>)
             </emphasis>
             .
         </para>
         <para>
-            So the total error is 
+            So the total error is
             <emphasis>
                 number of steps * O(h<superscript>5</superscript>)
             </emphasis>
-            . And since <emphasis>number of steps = interval size / h</emphasis> by definition, the total error is in 
+            . And since <emphasis>number of steps = interval size / h</emphasis> by definition, the total error is in
             <emphasis>
                 O(h<superscript>4</superscript>)
             </emphasis>
             .
         </para>
         <para>
-            That error analysis baptized the method <emphasis>implicit Runge-Kutta 4(5)</emphasis>: 
+            That error analysis baptized the method <emphasis>implicit Runge-Kutta 4(5)</emphasis>:
             <emphasis>
                 O(h<superscript>5</superscript>)
             </emphasis>
-            per step, 
+            per step,
             <emphasis>
                 O(h<superscript>4</superscript>)
             </emphasis>
             in total.
         </para>
         <para>
-            Although the solver works fine for <link linkend="Simulatemenu_Menu_entries">max step size</link> up to 
+            Although the solver works fine for <link linkend="Simulatemenu_Menu_entries">max step size</link> up to
             <emphasis>
                 10<superscript>-3</superscript>
             </emphasis>
-            , rounding errors sometimes come into play as we approach 
+            , rounding errors sometimes come into play as we approach
             <emphasis>
                 4*10<superscript>-4</superscript>
             </emphasis>
index 792d007..2fbdb6c 100644 (file)
@@ -61,7 +61,7 @@
                 \end{eqnarray}
             </latex>
             <para>
-                &#160; with, like in <link linkend="CVode">CVode</link>,
+                 with, like in <link linkend="CVode">CVode</link>,
                 <emphasis>
                     y<subscript>n</subscript>
                 </emphasis>
             </latex>
         </para>
         <para>
-            &#160; with <emphasis>J</emphasis> an approximation of the Jacobian:
+             with <emphasis>J</emphasis> an approximation of the Jacobian:
         </para>
         <para>
-            &#160; <latex>
+             <latex>
                 J = \frac{\partial{G}}{\partial{y}} = \frac{\partial{F}}{\partial{y}}+\alpha\frac{\partial{F}}{\partial{\dot{y}}}, \hspace{4 mm} \alpha = \frac{\alpha_{n,0}}{h_n},
             </latex>
         </para>
         <para>
-            &#160; <emphasis>&#x3B1;</emphasis> changes whenever the step size or the method order varies.
+             <emphasis>α</emphasis> changes whenever the step size or the method order varies.
         </para>
         <para>
             An implemented direct dense solver is used and we go on to the next step.
index 2e62302..6b9aaa3 100644 (file)
@@ -61,7 +61,7 @@
                 \end{eqnarray}
             </latex>
             <para>
-                &#160; with, like in <link linkend="CVode">CVode</link>,
+                 with, like in <link linkend="CVode">CVode</link>,
                 <emphasis>
                     y<subscript>n</subscript>
                 </emphasis>
                     </latex>
                 </para>
                 <para>
-                    &#160; with <emphasis>J</emphasis> an approximation of the Jacobian:
+                     with <emphasis>J</emphasis> an approximation of the Jacobian:
                 </para>
                 <para>
-                    &#160; <latex>
+                     <latex>
                         J = \frac{\partial{G}}{\partial{y}} = \frac{\partial{F}}{\partial{y}}+\alpha\frac{\partial{F}}{\partial{\dot{y}}}, \hspace{4 mm} \alpha = \frac{\alpha_{n,0}}{h_n},
                     </latex>
                 </para>
                 <para>
-                    &#160; <emphasis>&#x3B1;</emphasis> changes whenever the step size or the method order varies.
+                     <emphasis>α</emphasis> changes whenever the step size or the method order varies.
                 </para>
                 <para>
                     Then, an implemented direct dense solver is used and we go on to the next step.
index 837b575..7412d41 100644 (file)
@@ -100,7 +100,7 @@ try xcos_simulate(scs_m, 4); catch disp(lasterror()); end
             Now, in the two following scripts, we test the computational overhead of the rootfinding with <emphasis>LSodar</emphasis>:
         </para>
         <para>
-            First, a Sine function that crosses zero every &#960; period:
+            First, a Sine function that crosses zero every π period:
             <link type="scilab" linkend ="scilab.scinotes/xcos/examples/solvers/Rootfinding.sce">
                 Open the script
             </link>
index 83651c8..4d8f80e 100644 (file)
             <tr>
                 <td align="left">EMax</td>
                 <td align="left">40</td>
-                <td align="left">if x &gt; EMax, the exp(x) function is linearized</td>
+                <td align="left">if x > EMax, the exp(x) function is linearized</td>
             </tr>
         </informaltable>
     </refsection>
index bc37bcb..f30ad9e 100644 (file)
             <tr>
                 <td align="left">EMax</td>
                 <td align="left">40</td>
-                <td align="left">if x &gt; EMax, the exp(x) function is linearized</td>
+                <td align="left">if x > EMax, the exp(x) function is linearized</td>
             </tr>
         </informaltable>
     </refsection>
index 84424da..f716035 100644 (file)
         <itemizedlist>
             <listitem>
                 <para>
-                    <emphasis role="bold">decomposition type (1=Complex2MAG&amp;amp;PHI 2=MAG&amp;amp;PHI2Complex)</emphasis>
+                    <emphasis role="bold">decomposition type (1=Complex2MAG&amp;PHI 2=MAG&amp;PHI2Complex)</emphasis>
                 </para>
                 <para>Il indique la règle de conversion.</para>
                 <para>Propriétés : Type 'vec' de taille 1.</para>
index 382f499..87277a1 100644 (file)
         <itemizedlist>
             <listitem>
                 <para>
-                    <emphasis role="bold">decomposition type (1=Complex2Real&amp;amp;Imag 2=Real&amp;amp;Imag2Complex)</emphasis>
+                    <emphasis role="bold">decomposition type (1=Complex2Real&amp;Imag 2=Real&amp;Imag2Complex)</emphasis>
                 </para>
                 <para> Indique le type de décomposition utilisé. Voir la partie description pour plus d'information.</para>
                 <para> Propriétés : Type 'vec' de taille 1.</para>
index 656e746..bb62080 100644 (file)
             </listitem>
             <listitem>
                 <para>
-                    <emphasis role="bold">decomposition type (1=singular values 2=sing values+matrix U &amp;amp; V)</emphasis>
+                    <emphasis role="bold">decomposition type (1=singular values 2=sing values+matrix U &amp; V)</emphasis>
                 </para>
                 <para>
                     Indique la forme de la sortie. Quand il est mis à 1, nous avons une sortie unique vectorielle
index 5f71cee..a5453a5 100644 (file)
@@ -145,11 +145,11 @@ Temps pour Adams / Functional :
             ]]></screen>
         </para>
         <para>
-            Ces résultats montrent que pour un problème non-raide, à même précision demandée, <emphasis>LSodar</emphasis> est significativement plus rapide. D'autres tests ont montré la proximité des résultats. En effet, on trouve que l'écart entre les solutions de <emphasis>LSodar</emphasis> et <emphasis>CVode</emphasis> est de l'ordre de la plus haute tolérance ( 
+            Ces résultats montrent que pour un problème non-raide, à même précision demandée, <emphasis>LSodar</emphasis> est significativement plus rapide. D'autres tests ont montré la proximité des résultats. En effet, on trouve que l'écart entre les solutions de <emphasis>LSodar</emphasis> et <emphasis>CVode</emphasis> est de l'ordre de la plus haute tolérance (
             <emphasis>
                 y<subscript>lsodar</subscript> - y<subscript>cvode</subscript>
             </emphasis>
-            &#8776; <emphasis>max(reltol, abstol)</emphasis> ).
+            ≈ <emphasis>max(reltol, abstol)</emphasis> ).
         </para>
         <para>
             Les solveurs d'EDO à pas variable ne sont pas appropriés pour des applications temps réel déterministes car le surplus de calcul au passage d'un pas de temps varie au cours de l'application.
index 16663ad..8bcdf20 100644 (file)
             </latex>
         </para>
         <para>
-            Partant de 
+            Partant de
             <emphasis>
                 y<subscript>0</subscript>
             </emphasis>
-            , <emphasis>CVode</emphasis> approxime 
+            , <emphasis>CVode</emphasis> approxime
             <emphasis>
                 y<subscript>n+1</subscript>
             </emphasis>
                 \end{eqnarray}
             </latex>
             <para>
-                &#160; avec 
+                 avec
                 <emphasis>
                     y<subscript>n</subscript>
                 </emphasis>
-                l'approximation de 
+                l'approximation de
                 <emphasis>
                     y(t<subscript>n</subscript>)
                 </emphasis>
-                , et 
+                , et
                 <emphasis>
                     h<subscript>n</subscript>
                 </emphasis>
@@ -66,7 +66,7 @@
             </para>
         </para>
         <para>
-            Ces méthodes implicites sont caractérisées par leur order <emphasis>q</emphasis>, qui indique le nombre de points intermédiaires requis pour le calcul de 
+            Ces méthodes implicites sont caractérisées par leur order <emphasis>q</emphasis>, qui indique le nombre de points intermédiaires requis pour le calcul de
             <emphasis>
                 y<subscript>n+1</subscript>
             </emphasis>
             </listitem>
         </itemizedlist>
         <para>
-            Les coefficients sont fixes, déterminés uniformément par le type de méthode, son ordre, les pas de temps et la normalisation 
+            Les coefficients sont fixes, déterminés uniformément par le type de méthode, son ordre, les pas de temps et la normalisation
             <emphasis>
-                &#x3B1;<subscript>n, 0</subscript> = -1
+                α<subscript>n, 0</subscript> = -1
             </emphasis>
             .
         </para>
             Ce système peut être résolu par des itérations <emphasis>fonctionnelles</emphasis> ou de <emphasis>Newton</emphasis>, décrites ci-après.
         </para>
         <para>
-            Dans les deux cas suivants, le 
+            Dans les deux cas suivants, le
             <emphasis>
                 y<subscript>n(0)</subscript>
             </emphasis>
         <itemizedlist>
             <para>  </para>
             <listitem>
-                <emphasis role="bold">Fonctionnelles :</emphasis> cette méthode n'implique que des évaluations de <emphasis>f</emphasis>, elle calcule 
+                <emphasis role="bold">Fonctionnelles :</emphasis> cette méthode n'implique que des évaluations de <emphasis>f</emphasis>, elle calcule
                 <emphasis>
                     y<subscript>n(0)</subscript>
                 </emphasis>
                 simplement en itérant la formule :
                 <para>
                     <latex>
-                        y_{n(m+1)} = h_n &#x3B2;_{n,0} f(t_n,y_{n(m)}) + a_n
+                        y_{n(m+1)} = h_n β_{n,0} f(t_n,y_{n(m)}) + a_n
                     </latex>
                     <latex scilab:localized="true">
                         où \hspace{2 mm} a_n\equiv \sum_{i>0} (\alpha_{n,i} y_{n-i} + h_n\beta_{n,i}\dot{y}_{n-i})
             </listitem>
         </itemizedlist>
         <para>
-            Dans les deux cas, <emphasis>CVode</emphasis> se sert des valeurs passées pour contrôler l'erreur locale 
+            Dans les deux cas, <emphasis>CVode</emphasis> se sert des valeurs passées pour contrôler l'erreur locale
             <emphasis>
                 y<subscript>n(m)</subscript> - y<subscript>n(0)</subscript>
             </emphasis>
-            et recalcule 
+            et recalcule
             <emphasis>
                 h<subscript>n</subscript>
             </emphasis>
index b79c8ed..935ee11 100644 (file)
@@ -38,7 +38,7 @@
             Cette méthode est explicite, donc non concernée par les itérations fonctionnelles ou de Newton, et est déconseillée pour les problèmes raides.
         </para>
         <para>
-            C'est une amélioration de la méthode d'Euler, qui approxime 
+            C'est une amélioration de la méthode d'Euler, qui approxime
             <emphasis>
                 y<subscript>n+1</subscript>
             </emphasis>
             Une différence notable de <emphasis>Runge-Kutta</emphasis> par rapport à <emphasis>Sundials</emphasis> est qu'il calcule jusqu'à la septième dérivée de <emphasis>y</emphasis>, alors que les autres n'utilisent que des combinaisons linéaires de <emphasis>y</emphasis> et <emphasis>y'</emphasis>.
         </para>
         <para>
-            Ici, la valeur suivante est déterminée par la valeur actuelle 
+            Ici, la valeur suivante est déterminée par la valeur actuelle
             <emphasis>
                 y<subscript>n</subscript>
             </emphasis>
             plus la moyenne pondérée de six incréments, où chaque incrément est le produit du pas, <emphasis>h</emphasis>, et une estimation de la pente spécifiée par la fonction <emphasis>f(t,y)</emphasis> :
             <itemizedlist>
                 <listitem>
-                    <emphasis>k1</emphasis> est l'incrément basé sur la pente au début de l'intervalle, utilisant 
+                    <emphasis>k1</emphasis> est l'incrément basé sur la pente au début de l'intervalle, utilisant
                     <emphasis>
                         y<subscript>n</subscript>
                     </emphasis>
             </itemizedlist>
         </para>
         <para>
-            On peut voir qu'avec les <emphasis>ki</emphasis>, on progresse dans les dérivées de 
+            On peut voir qu'avec les <emphasis>ki</emphasis>, on progresse dans les dérivées de
             <emphasis>
                 y<subscript>n</subscript>
             </emphasis>
-            . Dans le calcul des <emphasis>ki</emphasis>, on utilise délibérément des coefficients qui donnent une erreur en 
+            . Dans le calcul des <emphasis>ki</emphasis>, on utilise délibérément des coefficients qui donnent une erreur en
             <emphasis>
                 O(h<superscript>5</superscript>)
             </emphasis>
             à chaque pas.
         </para>
         <para>
-            L'erreur totale est donc en 
+            L'erreur totale est donc en
             <emphasis>
                 nombre de pas * O(h<superscript>5</superscript>)
             </emphasis>
-            . Et puisque par définition <emphasis>nombre de pas = taille de l'intervalle / h</emphasis>, l'erreur totale est en 
+            . Et puisque par définition <emphasis>nombre de pas = taille de l'intervalle / h</emphasis>, l'erreur totale est en
             <emphasis>
                 O(h<superscript>4</superscript>)
             </emphasis>
             .
         </para>
         <para>
-            Cette analyse d'erreur a baptisé la méthode <emphasis>Dormand-Prince 4(5)</emphasis>: 
+            Cette analyse d'erreur a baptisé la méthode <emphasis>Dormand-Prince 4(5)</emphasis>:
             <emphasis>
                 O(h<superscript>5</superscript>)
             </emphasis>
-            par pas de temps, 
+            par pas de temps,
             <emphasis>
                 O(h<superscript>4</superscript>)
             </emphasis>
             au total.
         </para>
         <para>
-            Bien que le solveur fonctionne bien pour <link linkend="Simulatemenu_Menu_entries">max step size</link> jusqu'à 
+            Bien que le solveur fonctionne bien pour <link linkend="Simulatemenu_Menu_entries">max step size</link> jusqu'à
             <emphasis>
                 10<superscript>-3</superscript>
             </emphasis>
-            , des erreurs d'arrondi surviennent parfois quand l'on approche 
+            , des erreurs d'arrondi surviennent parfois quand l'on approche
             <emphasis>
                 4*10<superscript>-4</superscript>
             </emphasis>
index a6c3d13..7543430 100644 (file)
             Cette méthode étant implicite, elle peut être utilisée sur des problèmes raides.
         </para>
         <para>
-            C'est une amélioration de la méthode d'Euler implicite, qui approxime 
+            C'est une amélioration de la méthode d'Euler implicite, qui approxime
             <emphasis>
                 y<subscript>n+1</subscript>
             </emphasis>
-            en calculant 
+            en calculant
             <emphasis>
                 f(t<subscript>n</subscript>+h, y<subscript>n+1</subscript>)
             </emphasis>
             Une différence notable de <emphasis>Runge-Kutta implicite</emphasis> par rapport à <emphasis>Sundials</emphasis> est qu'il calcule jusqu'à la dérivée quatrième de <emphasis>y</emphasis>, alors que les autres n'utilisent que des combinaisons linéaires de <emphasis>y</emphasis> et <emphasis>y'</emphasis>.
         </para>
         <para>
-            Ici, la valeur suivante est déterminée par la valeur actuelle 
+            Ici, la valeur suivante est déterminée par la valeur actuelle
             <emphasis>
                 y<subscript>n</subscript>
             </emphasis>
             plus la moyenne pondérée de trois increments, où chaque incrément est le produit du pas, <emphasis>h</emphasis>, et une estimation de la pente spécifiée par la fonction <emphasis>f(t,y)</emphasis>. Ils sont distribués de manière à peu près égale sur l'intervalle.
             <itemizedlist>
                 <listitem>
-                    <emphasis>k1</emphasis> est l'incrément basé sur la pente au début de l'intervalle, utilisant 
+                    <emphasis>k1</emphasis> est l'incrément basé sur la pente au début de l'intervalle, utilisant
                     <emphasis>
                         y<subscript>n</subscript>+ a11*h*k1,
                     </emphasis>
                     ,
                 </listitem>
                 <listitem>
-                    <emphasis>k2</emphasis> est l'incrément basé sur la pente près du milieu de l'intervalle, utilisant 
+                    <emphasis>k2</emphasis> est l'incrément basé sur la pente près du milieu de l'intervalle, utilisant
                     <emphasis>
                         y<subscript>n</subscript> + a21*h*k1 + a22*h*k2,
                     </emphasis>
                     ,
                 </listitem>
                 <listitem>
-                    <emphasis>k3</emphasis> est l'incrément basé sur la pente trois quarts de l'intervalle, utilisant 
+                    <emphasis>k3</emphasis> est l'incrément basé sur la pente trois quarts de l'intervalle, utilisant
                     <emphasis>
                         y<subscript>n</subscript> + a31*h*k1 + a32*h*k2 + a33*h*k3.
                     </emphasis>
             On peut voir que le calcul d'un <emphasis>ki</emphasis> requiert <emphasis>ki</emphasis>, nécéssitant ainsi l'utilisation d'un solveur non linéraire (ici, itérations point-fixes).
         </para>
         <para>
-            D'abord, on initialise 
+            D'abord, on initialise
             <emphasis>
                 k0 = h * f(t<subscript>n</subscript>, y<subscript>n</subscript>)
             </emphasis>
-            comme première estimation pour tous les <emphasis>ki</emphasis>, pour obtenir de nouveaux <emphasis>ki</emphasis> et une première valeur pour 
+            comme première estimation pour tous les <emphasis>ki</emphasis>, pour obtenir de nouveaux <emphasis>ki</emphasis> et une première valeur pour
             <emphasis>
                 y<subscript>n+1</subscript>
             </emphasis>
             .
         </para>
         <para>
-            Ensuite, on sauve les valeurs et on recalcule 
+            Ensuite, on sauve les valeurs et on recalcule
             <emphasis>
                 y<subscript>n+1</subscript>
             </emphasis>
             avec ces nouveaux <emphasis>ki</emphasis>.
         </para>
         <para>
-            Puis on compare les deux 
+            Puis on compare les deux
             <emphasis>
                 y<subscript>n+1</subscript>
             </emphasis>
             Ce processus ajoute un temps de calcul significatif à la méthode, mais améliore grandement la stabilité.
         </para>
         <para>
-            On peut voir qu'avec les <emphasis>ki</emphasis>, on progresse dans les dérivées de 
+            On peut voir qu'avec les <emphasis>ki</emphasis>, on progresse dans les dérivées de
             <emphasis>
                 y<subscript>n</subscript>
             </emphasis>
-            . Donc avec <emphasis>k3</emphasis>, on approxime 
+            . Donc avec <emphasis>k3</emphasis>, on approxime
             <emphasis>
                 y<superscript>(3)</superscript><subscript>n</subscript>
             </emphasis>
-            , faisant donc une erreur en 
+            , faisant donc une erreur en
             <emphasis>
                 O(h<superscript>4</superscript>)
             </emphasis>
-            . Mais un choix judicieux des coefficients du calcul des <emphasis>ki</emphasis> (notamment 
+            . Mais un choix judicieux des coefficients du calcul des <emphasis>ki</emphasis> (notamment
             <emphasis>
                 a<subscript>ij</subscript>
             </emphasis>
-            ) nous fait gagner un order, produisant ainsi une erreur par pas de temps en 
+            ) nous fait gagner un order, produisant ainsi une erreur par pas de temps en
             <emphasis>
                 O(h<superscript>5</superscript>)
             </emphasis>
             .
         </para>
         <para>
-            L'erreur totale est donc 
+            L'erreur totale est donc
             <emphasis>
                 nombre de pas * O(h<superscript>5</superscript>)
             </emphasis>
-            . Et puisque par définition <emphasis>nombre de pas = taille de l'intervalle / h</emphasis>, l'erreur totale est en 
+            . Et puisque par définition <emphasis>nombre de pas = taille de l'intervalle / h</emphasis>, l'erreur totale est en
             <emphasis>
                 O(h<superscript>4</superscript>)
             </emphasis>
             .
         </para>
         <para>
-            Cette analyse d'erreur a baptisé la méthode <emphasis>Runge-Kutta Implicite 4(5)</emphasis>: 
+            Cette analyse d'erreur a baptisé la méthode <emphasis>Runge-Kutta Implicite 4(5)</emphasis>:
             <emphasis>
                 O(h<superscript>5</superscript>)
             </emphasis>
-            par pas, 
+            par pas,
             <emphasis>
                 O(h<superscript>4</superscript>)
             </emphasis>
             au total.
         </para>
         <para>
-            Bien que le solveur fonctionne bien pour <link linkend="Simulatemenu_Menu_entries">max step size</link> jusqu'à 
+            Bien que le solveur fonctionne bien pour <link linkend="Simulatemenu_Menu_entries">max step size</link> jusqu'à
             <emphasis>
                 10<superscript>-3</superscript>
             </emphasis>
-            , es erreurs d'arrondi surviennent parfois quand l'on approche 
+            , es erreurs d'arrondi surviennent parfois quand l'on approche
             <emphasis>
                 4*10<superscript>-4</superscript>
             </emphasis>
index 73836b3..efc4c66 100644 (file)
@@ -61,7 +61,7 @@
                 \end{eqnarray}
             </latex>
             <para>
-                &#160; avec, comme dans <link linkend="CVode">CVode</link>,
+                 avec, comme dans <link linkend="CVode">CVode</link>,
                 <emphasis>
                     y<subscript>n</subscript>
                 </emphasis>
             </latex>
         </para>
         <para>
-            &#160; avec <emphasis>J</emphasis> une approximation du Jacobien:
+             avec <emphasis>J</emphasis> une approximation du Jacobien:
         </para>
         <para>
-            &#160; <latex>
+             <latex>
                 J = \frac{\partial{G}}{\partial{y}} = \frac{\partial{F}}{\partial{y}}+\alpha\frac{\partial{F}}{\partial{\dot{y}}}, \hspace{4 mm} \alpha = \frac{\alpha_{n,0}}{h_n},
             </latex>
         </para>
         <para>
-            &#160; <emphasis>&#x3B1;</emphasis> change quand le pas ou l'ordre de la méthode varient.
+             <emphasis>α</emphasis> change quand le pas ou l'ordre de la méthode varient.
         </para>
         <para>
             Un solveur direct dense est alors utilisé et on poursuit sur le prochain pas de temps.
index 4fff755..8f9b272 100644 (file)
@@ -61,7 +61,7 @@
                 \end{eqnarray}
             </latex>
             <para>
-                &#160; avec, comme dans <link linkend="CVode">CVode</link>,
+                 avec, comme dans <link linkend="CVode">CVode</link>,
                 <emphasis>
                     y<subscript>n</subscript>
                 </emphasis>
                     </latex>
                 </para>
                 <para>
-                    &#160; avec <emphasis>J</emphasis> une approximation du Jacobien :
+                     avec <emphasis>J</emphasis> une approximation du Jacobien :
                 </para>
                 <para>
-                    &#160; <latex>
+                     <latex>
                         J = \frac{\partial{G}}{\partial{y}} = \frac{\partial{F}}{\partial{y}}+\alpha\frac{\partial{F}}{\partial{\dot{y}}}, \hspace{4 mm} \alpha = \frac{\alpha_{n,0}}{h_n},
                     </latex>
                 </para>
                 <para>
-                    &#160; <emphasis>&#x3B1;</emphasis> change quand le pas ou l'ordre de la méthode varient.
+                     <emphasis>α</emphasis> change quand le pas ou l'ordre de la méthode varient.
                 </para>
                 <para>
                     Un solveur direct dense est alors utilisé et on poursuit sur le prochain pas de temps.
index ebee132..41311a3 100644 (file)
@@ -101,7 +101,7 @@ try xcos_simulate(scs_m, 4); catch disp(lasterror()); end
             Dans les scripts suivants, on test le surplus de calcul de la détection de racines avec <emphasis>LSodar</emphasis> :
         </para>
         <para>
-            D'abord, un Sinus traversant zéro toutes les &#960; périodes :
+            D'abord, un Sinus traversant zéro toutes les π périodes :
             <link type="scilab" linkend ="scilab.scinotes/xcos/examples/solvers/Rootfinding.sce">
                 Ouverture du script
             </link>