Changes between Version 3 and Version 4 of OfficialTolArchiveNetworkMWG

Timestamp:

Jul 5, 2011, 10:15:35 PM (14 years ago)

Author:

Víctor de Buen Remiro

Comment:

--

OfficialTolArchiveNetworkMWG

@@ -18 +18 @@
 
 Si se conoce un método eficaz para simular cada bloque condicionado al resto entonces es aplicable 
-el método de simulación de Gibbs. Si no es el caso pero sí es posible evaluar la función de 
-log-verosimilitud salvo constante condicionada al resto de bloques
+el método de simulación de Gibbs por bloques. 
+
+Normalmente resulta mucho más sencillo evaluar la función de log-verosimilitud salvo constante condicionada 
+al resto de bloques, 
 
 [[LatexEquation( \ln\pi_{i}\left(\left.\Omega_{i}\right|\Omega_{j\neq i}\right) )]]
 
-entonces el método a aplicar se llama ''Metropolis within Gibbs'', que consiste en simular 
-alternativamente los distintos bloques con el método de Metropolis-Hastigs (MH) o alguno similar 
-como el Multiple Try Metroplis (MTM), dejando invariantes todos aquellos de los que depende. En cada 
-simulación es necesario evaluar la log-verosimilitud un número de veces dependiente del método usado.
+lo cual permite aplicar el método Metropolis Within Gibbs, que consiste en simular 
+alternativamente los distintos bloques con el método de Metropolis-Hastigs (MH) o alguno similar como el 
+Multiple Try Metroplis (MTM), dejando invariantes todos aquellos de los que depende. En cada simulación 
+es necesario evaluar la log-verosimilitud un número de veces dependiente del método usado.
+
+Este esquema tiene la ventaja de que sirve para simular cualquier clase de modelos implementando bloques de 
+simulación para cada tipo de elemento que intervenga y definiendo aparte las relaciones de condicionamiento 
+como meras reglas de asignación total o parcial de miembros de un bloque condicionado en función de los 
+miembros del bloque condicionante. 
+
+Si para un bloque concreto se dispone de un método de generación condicionada que resulte más sencillo o 
+eficaz que el MH o sus derivados, es perfectamente lícito aplicarlo siempre y cuando se respeten las 
+relaciones de condicionamiento. 
 
 == Arquitectura del sistema ==
@@ -67 +78 @@
 mucho menos trivial condicionar de una forma genérica y eficiente. 
 
-Existen pues tres entidades en el sistema, cada una de las cuales dará lugar a una jerarquía de clases 
-que permita adaptarse a todas las situaciones con una API mínima.
+Existen varias entidades en el sistema, algunas de las cuales darán lugar a una jerarquía de clases 
+que permitirán adaptarse a todas las situaciones con una API mínima, mientras que otros conceptos son 
+relativos al uso y no a su estructura por lo que no precisan de una clase
 
  * {{{@RandVar}}}: Variable aleatoria generable mediante log-verosimilitud, sin perjuicio de que pueda haber
-   otro método de generación alternativo más eficaz en alguna clase heredada.
+   otro método de generación alternativo más eficaz en alguna clase heredada. 
  * {{{@Relation}}}: Relación entre un bloque condicionante y otro condicionado que especifica sin ambigüedad 
    posible todas las acciones a realizar.
- * {{{@Model}}}: Conjunto de variables aleatorias y de relaciones de condicioanmiento. Es un tipo especial 
-   de variale aleatoria, por lo que hereda de {{{@RandVar}}}.
+ * {{{@Model}}}: Conjunto de bloques de variables aleatorias y de relaciones de condicioanmiento. Es un 
+   tipo especial de variale aleatoria, por lo que hereda de {{{@RandVar}}}.
+ * Bloque: Variable aleatoria cuyo generador es llamado por un modelo según una estrategia de ejecución. 
+   de algún modo compatible con el algoritmo de Gibbs. Un modelo puede funcionar como un bloque de otro modelo.
+ * Estrategia: Forma de alternar o simultanear la simulación de los distintos bloques de Gibbs, de forma 
+   compatible con la estructura de relaciones. 
+ * Master: Modelo principal formado por bloques que pueden ser a su vez modelos y que lanza las simulaciones 
+   de cada uno de ellos según la estrategia seleccionada y la va almacenando en disco. 
 
 == Clase {{{@RandVar}}} ==
-A la clase base de la que derivan todos los bloques la llamaremos {{{Class @RandVar}}}, pues lo que 
-se está planteando no es otra cosa que un mecanismo de gestión de variables aleatorias. 
+A la clase base de la que derivan todos las variables aleatorias (v.a.) la llamaremos {{{Class @RandVar}}}, pues 
+lo que se está planteando no es otra cosa que un mecanismo de gestión de variables aleatorias por la 
+vía de la generación de simulaciones por uno u otro método. 
+
+No toda v.a. definida tiene porqué ser un bloque de Gibbs de un modelo. Muchas veces un bloque 
+se puede definir mediante operaciones algebraicas de otras variables aleatorias las cuales no pertenecerán 
+directamente al modelo sino indirectamente a través de uno de sus bloques. Otro tipo de v.a. de gran
+utilidad serán las que definan la información ''a priori'' relativa a un bloque o a un modelo, simplemente
+sumando su log-verosimilitud.
 
 En este nivel raíz estará disponible una batería de algoritmos de generación MCMC basados en la
@@ -104 +129 @@
 que exista otro método directo más eficaz de muestreo.
 
-Cuando no existe dicho método directo la clase derivada final debe implementar obligatoriamente el 
-método que devuelve el logaritmo de la verosimilitud para poder aplicar alguno de los métodos MCMC
+Cuando no existe dicho método directo la clase derivada final, ésta debe implementar obligatoriamente 
+el método que devuelve el logaritmo de la verosimilitud para poder aplicar alguno de los métodos MCMC
 {{{
 #!java