Input's error in estimate function.

[mafernandez]

Consider the following code:

Set mod = ModelDef(
  Serie SubSer(Gaussian(10,1,C),y2009m01d01,y2010m01d01),
  1,
  0,
  0,
  0,
  Polyn 1, 
  [[Polyn 1]],
  [[Polyn 1]], 
  [[
    InputDef(Polyn 0.1-0.1*B, Serie input1 = SubSer(Gaussian(10,1,C),y2008m12d31,y2010m01d01)),
    InputDef(Polyn 0.1,       Serie input2 = SubSer(Gaussian(10,1,C),y2009m01d01,y2010m01d01))
  ]], 
  Empty);


Set Estimate(mod);

It returns the following error:

ERROR: [1] input2 tiene valores desconocidos en 0  

It seems that input2 is also retarded as input1 was. Any reason for that?

[pgea@…]

Parece claro que Estimate se "equivoca" al solicitar a todos los inputs datos en el mismo intervalo de tiempo:

Empieza Carga de datos
Cargando datos de la serie output entre y2009m01d01 y y2010m01d01
Norma de la serie output diferenciada : 0.995308262980787
=> Cargando datos de series input entre y2008m12d31 y y2010m01d01
ERROR: [1] input2 tiene valores desconocidos en 0

No sé si es una cuestión dificil de solucionar, por el momento estamos concatenando ceros por la izquierda con el "convencimiento" de que no los va a usar para nada.

[Víctor de Buen Remiro]

Perdón porque parece que este ticket se me había escapado.
No he podido mirarlo a fondo y puede que se me esté pasando algo, pero a mí me parece que lo que ocurre es que ese input tiene asignado un omega de grado 1, por lo cual es lógico que necesite un dato anterior.

[pgea@…]

Han surgido nuevas cuestiones relacionadas con este tique en el desarrollo de MMS.

Ya que al parecer los datos concatenados a la izquierda que considerabamos que no afectarían al cálculo, sí que afectan en el caso de existir parámetros ARMA.

Repaso el problema:

Cuando Estimate recibe varios inputs y uno de ellos tiene un polinomio omega de grado mayor que los demás, Estimate quiere conocer el histórico de los inputs (de todos) con esa anterioridad que indica el grado de ese polinomio omega.

En principio consideramos que eso era un error y concatenamos ceros a la izquierda por defecto pensando que esos datos a la izquierda no importaban, pero parece ser que esto no es así, y sí que importan al menos cuando en la estimación hay involucrado algún parámetro ARIMA (véase el ejemplo adjunto).

No sé si se trata realmente de un error, pero en cualquier caso sorprende un poco que algoritmo necesite o utilice esos datos anteriores.

Adjunto un ejemplo de output y dos inputs uno con un polinomio omega de grado dos y el otro con uno de grado cero. Para conseguir estimar pruebo tres opciones: (1) concatenar ceros por la izquierda al input2, (2) concatenar unos valores altos para comprobar que interfieren en el cálculo, (3) separar el input1 en dos inputs con polinomios de grado cero. La solución aunque pueda ser parecida es distinta en los tres casos.

[Víctor de Buen Remiro]

Hay una cuarta posibilidad que es lo que se hace normalmente en todos los proyectos que es perder un dato por el principio y empezar a estimar una fecha más tarde.

Intentaré ver qué pasa con eso pero ya adelanto que ha habido muchos intentos de arreglarlo y nunca se ha conseguido, pues la casuística es demasiado extensa, hay demasiadas cosas que pueden ocurrir, cada vez que se arregla algo se desarreglan otras 10 cosas donde menos te lo esperas y me preocupa que se pierda la compatibilidad hacia atrás.

Fue un error de diseño plantear el Estimate con objetos de tipo Serie por las dificultades que entraña el manejo de objetos virtualemente infinitos en C++. Precisamente por eso desde entonces todos los algoritmos se desarrollan para matrices y el manejo del tiempo se realiza en el propio código TOL del usuario.

[Víctor de Buen Remiro]

(In [1997]) Fixed #786