close Warning: Can't synchronize with repository "(default)" (/var/svn/tolp does not appear to be a Subversion repository.). Look in the Trac log for more information.

Opened 14 years ago

Last modified 14 years ago

#997 closed defect

[BysMcmc] El filtro no lineal DeltaTransfer no tiene en cuenta los valores iniciales del numerador — at Version 2

Reported by: Víctor de Buen Remiro Owned by: Víctor de Buen Remiro
Priority: highest Milestone: BSR extensions
Component: Math Version: head
Severity: blocker Keywords:
Cc: Pedro Gea, Jorge

Description (last modified by Víctor de Buen Remiro)

El argumento Matrix x0 de BysMcmc::Bsr::Gibbs::DeltaTransfer se almacena en el miembro Matrix _.x0 y sólo se usa en el método eval en la línea

    Matrix _.y := DifEq(1/_.delta, _.x, _.x0, _.y0q);

en la que en realidad no es tenido en cuenta para nada por ser 1 el numerador de la ecuación en diferencias.

De hecho no se crean en ningún caso parámetros en el bloque correspondientes a dichos valores iniciales, lo cual es al menos consecuente con el hecho de que no se usen en absoluto.

Change History (2)

comment:1 Changed 14 years ago by Víctor de Buen Remiro

Status: newaccepted
Summary: [BysMcmc] El filtro no lineal DeltaTransfer no tiene en cuenta los valores iniciales[BysMcmc] El filtro no lineal DeltaTransfer no tiene en cuenta los valores iniciales del numerador

comment:2 Changed 14 years ago by Víctor de Buen Remiro

Description: modified (diff)

La forma más eficaz de estimar la función de transferencia no lineal involucra en realidad a dos bloques, distintos:

  • coeficientes delta y valores iniciales de la ecuación en diferencias: pertenecen explícitamente al bloque no lineal y se simulan por un método escalar genérico aunque poco eficiente (ARMS, SLICE ...)
  • coeficientes omega: pertenecen al bloque lineal por lo que se simulan muy eficazmente. Para ello se introduce para cada monomio
       omega[k] = coef[k]*B^deg[k]
    
    del polinomio omega un input y[k] correspondiente a la solución de la ecuación en diferencias
       _.delta(B) : y[k,t] = B^deg[k] : _.x
    
    El parámetro lineal correspondiente a cada uno de estos inputs será el coeficiente coef[k] buscado.

Al tener el mismo denominador la solución general (la correspondiente al caso homogéneo o valores iniciales nulos) de cada una de esas ecuaciones es en realidad una simple traslación de deg[k] hacia atrás en el tiempo de la solución general de la ecuación en diferencias

   _.delta(B) : y[k,t] = 1 : _.x

Así que sólo es necesario resolver la ecuación en diferencias una vez en lo que respecta a la solución general.

El problema es que eso es cierto para las soluciones generales de las ecuaciones en diferencias, pero no así para las soluciones particulares para unas condiciones iniciales dadas.

Simplemente hay que explicitar el cálculo para cada monomio omega[k] y el problema estaría resuelto correctamente, aunque resultará algo más lento que lo que hay ahora.

Podría incluso hacerse un chequeo para el caso de que se quieran fijar valores iniciales nulos en el input en cuyo caso funcionaría bien lo que hay ahora y sería más rápido en ejecución.

En el caso de que el grado del monomio omega sea 1 y el modelo esté diferenciado tampoco tiene importancia el lapsus, puesto que lo único que le falta a la solución general para ser la particular es la adición de una constante correspondiente al valor inicial en cuestión, así que una vez diferenciada la serie es indistinguible de la correcta. Lo mismo pasaría si no hubiera diferenciación en la parte ARIMA pero sí un input de nivel constante, pues éste anularía igualmente la discrepancia igualmente constante entre la solución general y la particular.

A la hora de añadir los parámetros _.x0 al bloque no lineal habrá que tener en cuenta precisamente este asunto pues en el caso de haber diferenciación, un input constante, o un conjunto de inputs que puedan sumar una combinación lineal constante, el parámetro inicial correspondiente al grado 1 (el último de _.x0) daría colinealidad y no podría introducirse como parámetro en el modelo sin un prior adecuado.

Análogamente, me temo que para los valores iniciales de grado superior se pueden dar otro tipo de circunstancias, que ahora mismo no veo tan claras como para el primero, que podrían dar lugar a colinealidades o quizás otro tipo de problemas numéricos.

Este tipo de problemas fue precisamente lo que me obligó a eliminar cautelarmente los parámetros iniciales _.x0 en su día. Luego la presión diaria me alejó de este asunto y se quedó el fallo enquistado ahí. Este alegato no pretende justificar ni excusar nada, sólo revelar la complejidad que encierra programar un simulador bayesiano medianamente robusto y eficaz, lo tremendamente entrelazado que está todo y lo fácil que es definir un modelo inválido que parece perfecto a primera vista.

Habría que decidir si queremos que los valores iniciales _.x0 sean fijos o variables, pero en este caso creo que deberían ir obligatoriamente acompañados de un prior.

Note: See TracTickets for help on using tickets.