Función AIA con fechados no globales.

[Iván Robles]

Buenas tardes,

La función AIA recibe un argumentos que es la serie de residuos. Si el TimeSet en el que se recibe la serie de residuos es un TimeSet no conocido, Tol da avisos de que no se conoce el TimeSet, y despues se cae.

El siguiente ejemplo crea una serie de residuos, que despues la transformamos en una función con un fechado que es local a la función, por lo que al salir de la función, el fechado es desconocido. Cuando despues se ejecuta la funcion AIA es cuando sucede lo comentado.

Codigo:

Serie residuos = SubSer(Gaussian(0,0.15),y2000,y2008);

Serie transformaTimeSet(Serie residuos){

  TimeSet nuevoTimeSet = Diario;
  Serie DatCh(residuos,nuevoTimeSet,FirstS)
  

};

Serie residuosNuevos = transformaTimeSet(residuos);
Set AIA(residuosNuevos,Ratio (1-0.1*B)/(1-0.1*B));

Gracias,
Un cordial saludo

[Víctor de Buen Remiro]

(In [1580]) Fixes #765

[Víctor de Buen Remiro]

(In [1582]) Fixes #765

[Víctor de Buen Remiro]

El problema ha sido resuelto.
La creación de los inputs candidatos a componentes de la salida del AIA se hacía vía evaluación de expresiones TOL del tipo

  InputDef(coef, RationExpand(date,datingName,ration_outlier_shape))

puesto que generar este tipo de objeto desde el propio C++ supone un arduo trabajo que el evaluador de TOL nos da hecho, aunque con el coste de no poder acceder por nombre a objetos fuera de ámbito.

Se ha llegado a una solución intermedia, creando directamnete en C++ la parte correspondiente a la serie

  RationExpand(date,datingName,ration_outlier_shape)

que ahora ya no necesita acceder por scope a datingName, sino directamente al puntero C++ del fechado de la serie. Ese objeto TOL se renombra internamente como un objeto TOL local

  RationExpand_<date>_ration_outlier_shape_name

para que entre en el scope y se llama al evaluador de TOL con la expresión

  InputDef(coef, RationExpand_<date>_ration_outlier_shape_name)

Finalmente para garantizar la compatibilidad hacia atrás se le pone como descripción al objeto resultante la expresión antigua

  InputDef(coef, RationExpand(date,datingName,ration_outlier_shape))

No obstante esta es una mala práctica, es muy peligrosa y puede tener efectos secundarios. Las series temporales tienen un tipo de relación muy especial con sus fechados que permite este tipo de incongruencias, de forma que la serie sobrevive al fechado local. Siempre es preferible que el fechado se cree en el ámbito en el que se va a usar, lo de menso es que sea global o local, lo que importa es que n ose use fuera de su ámbito. Además de preferible siempre es posible, quizás pueda suponer alguna incomodidad o algo de trabajo extra pero siempre es mucho más seguro y evita muchos quebraderos de cabeza.

Por ejemplo en este caso quizás podría ser algo así:

  Serie residuos = SubSer(Gaussian(0,0.2)+Pulse(y2004),y2000,y2008);

  TimeSet creaTimeSet(Serie res) {
    //Es de suponer que aquí irá una expresión compleja dependiente de res
     Diario
  };

  TimeSet nuevoTimeSet = creaTimeSet(residuos);

  Serie transformaTimeSet(Serie res) {
    Serie DatCh(residuos,nuevoTimeSet,FirstS)
  };

  Serie residuosNuevos = transformaTimeSet(residuos);
  Set aia = AIA(residuosNuevos,Ratio (1-0.1*B)/(1-0.1*B));

Si el problema es más complejo también podría pensarse en usar un NameBlock o incluso una Class para no usar objetos globales y mantener visible el fechado.