Changes between Version 15 and Version 16 of TolDocModelPlanIntegracionSistemasEstimacion

Timestamp:

Jun 21, 2011, 6:56:09 PM (14 years ago)

Author:

Víctor de Buen Remiro

Comment:

--

TolDocModelPlanIntegracionSistemasEstimacion

@@ -161 +161 @@
 y BSR que ataque directamente la estructura de datos manejada.
 
-Esta estructura Bsrde hecho debería ser replanteada como una clase para poder crecer y extenderse 
+Esta estructura Bsr de hecho debería ser replanteada como una clase para poder crecer y extenderse 
 de una forma más facil de mantener. Para asegurar la compatibilidad con el estado actual bastaría
-con tener un método que cree la instancia a parit
+con tener un método que cree la instancia a partir del struct actual.
 
 == Plan a medio-largo plazo ==
@@ -177 +177 @@
 El esquema de simulación más flexible para modelos tan generales sería un ''Metropolis within Gibbs''
 
- * ''División en bloques de Gibbs'': Debe haber un proceso maestro (master) que se encargue de disparar
+ * ''División en bloques de Gibbs'': Debe haber un '''proceso maestro''' (master) que se encargue de disparar
    la generación de cada bloque según una estrategia dada (secuencial, aleatoria o arbitraria). Al 
    contrario de lo que ocurre con el actual BSR, el proceso maestro no necesita conocer la 
@@ -184 +184 @@
    de forma condicionada al resto de bloques. Es necesario crear un protocolo básico de 
    condicionamiento entre bloques que sea totalmente general y no implique que ni el master 
-   ni los propios bloques tengan que conocer los intríngulis de los demás. Este protocolo formaría
-   parte de la definición del master y tendría la forma de una tabla con la estructura básica de 
-   enlace entre variables, que en cada fila incluiría estos campos: [[BR]]
+   ni los propios bloques tengan que conocer los intríngulis de los demás, y sea al mismo tiempo
+   suficientemente eficaz. Hay que tener en cuenta que la acción a llevar a cabo para condicionar 
+   puede suponer desde modificar simplemente un valor escalar (como la sigma de un bloque de 
+   regresión lineal normal), hasta modificar total o parcialmente un valor vectorial o matricial,
+   (como ocurre en el caso de los omitidos que deben trasladarse a un subconjunto arbitrariamente
+   salteado de entre las celdas de la matriz de input o de output). Por este motivo no resulta 
+   ni mucho menos trivial condicionar de una forma genérica y eficiente.
+   Posiblemente sea necesaria una función C++ a la que se le pase el miembro a modificar, los nuevos 
+   valores y una serie de argumentos opcionales para especificar modificaciones parciales, para
+   que la acción se ejecute con la celeridad debida.
+{{{
+#!java
+  Real ChangeValues({Real|Matrix|VMatrix} store, {Real|Matrix|VMatrix} newValues [, Set optArgs=Empty] ) 
+}}}
+   La función {{{ChangeValues}}} será llamada desde el master para establecer, total o parcialmente según 
+   se indique en los argumentos opcionales {{{optArgs}}}, el nuevo valor o vector de valores {{{newValues}}} 
+   de cierto miembro de un bloque que será el dado por el argumento {{{store}}}.
+   En la definición del master, el protocolo tendría la forma de una tabla con la estructura básica de 
+   condicionamiento, que en cada fila incluiría la información de condicionamiento de una variable o
+   grupo de variables: [[BR]]
 {{{ 
-  id_cnr_blk : índice del bloque condicionador
-  id_cnr_var : índice de la variable condionadora
-  id_cnd_blk : índice del bloque condicionado
-  id_cnd_var : índice de la variable condionada
+  Real cnr_blk : Índice del bloque condicionador
+  Set  cnr_idx : Índices de los parámetros del grupo dentro del bloque condicionador
+  Real cnd_blk : Índice del bloque condicionado
+  Text cnd_mbr : Nombre del miembro del bloque condicionado que se ha de modificar con {{{ChangeValues}}}
+  Set  cnd_opt : Argumentos opcionales para pasar como {{{optArgs}}} a {{{ChangeValues}}}
 }}}
-   Cada vez que se genera una muestra del i-ésimo bloque se debe modificar los valores correspondientes 
-   a los enlaces para los que id_cnr_blk = i
- * Generación dentro de cada bloque tipo ''Metropolis-Hastings'' y derivados mediante BysSampler o 
+   Cada vez que se genera una muestra del i-ésimo bloque hay que modificar los valores correspondientes 
+   a los enlaces para los que {{{cnr_blk = i}}}. Primero habría que copiar el sub-vector del bloque recién 
+   generado en la posición correspondiente dentro del vector conjunto, que será el que se almacene en 
+   el disco como cadena MCMC. Luego habría que llevar a cabo el condicionamiento de cada uno de los bloques
+   afectados llamando a {{{ChangeValues}}}.
+ * Generación dentro de cada bloque tipo ''Metropolis-Hastings'' y derivados mediante {{{BysSampler}}} o 
    cualquier otra metodología alternativa con tal cumpla una API mínima, pero siempre basado únicamente 
    en el logaritmo, salvo una constante, de la función de densidad condicionada por el resto de bloques. 
-
+   La parte más complicada a la hora de aplicar el condicionamiento es la que se refiere a la información 
+   a priori y restricciones que afectan a variables de distintos bloques. Cada bloque dispondrá de un método
+   que devolverá un listado de los nombres de los miembros susceptibles de ser condicionados [[BR]]
+{{{
+#!java
+  Set ConditionableList(Real void) 
+}}}
+