CalInd( W, ...) corrupted

[Jorge]

Attached is an oza file that corrupt the behaviour of CalInd( W, Daily).

Also is attached a test.tol

Serie S1 = SubSer( CalInd( W, Daily ), y2010, y2011m12 );
Set Include( "VC1.C56.22_data.oza" );
Serie S2 = SubSer( CalInd( W, Daily ), y2010, y2011m12 );
Serie S3 = S2 - S1;
Real check = MaxS( S3 );
WriteLn( "check must be 0 and it is " << check );

S1 is 0 as expected but S2 is 1 on every 21 of each month.

[Víctor de Buen Remiro]

(In [3517]) Refs #1199

[Víctor de Buen Remiro]

No consigo encontrar el motivo de este problema pero está bastante claro que es un problema de la caché surgido por algún efecto colateral que aparece al cargar el OIS.
La caché de conjuntos temporales es importantísima cuando se manejan expresiones complejas, especialemente cuando se combinan los Range y los Succ pues cada aparición eleva la complejidad algorítmica en un grado. Sin embargo en muchas instancias es innecesaria y hasta contraproducente, como sería el caso del conjunto vacío.
He encontrado una forma muy sencilla de que concretamente el TimeSet W no utilice la caché en el operador que estaba dando problema, lo cual resuelve este problema concreto pero está claro que hay que encontrar el problema general y resolverlo.
Tampoco es que se trate de un parche pues como decía antes, tiene toda la lógica del mundo que el conjunto vacío no use ningún tipo de caché, pues sus métodos son todos triviales y más eficaces en su forma analítica que con caché.
Se trataría más bien de una solución parcial pues, aparte de que hay que encontrar la causa concreta del problema, aún hay que revisar si existen otros métodos de W que estén usando la cache, y también está claro que existen otros conjuntos que pueden funcionar más eficazmente sin caché, a los que habría que aplicar el mismo criterio.
De hecho, no estaría de más programar una forma de deshabilitar y habilitar la caché en cada instancia de conjunto temporal, lo cual daría además un método de chequeo añadido.
En cuanto pase los tests subiré la versión binaria de windows tanto de la 2.0.1 como de la 2.0.2

[Víctor de Buen Remiro]

(In [3518]) Refs #1199

[Víctor de Buen Remiro]

(In [3521]) Refs #1199

[Víctor de Buen Remiro]

(In [3524]) Refs #1199
Making optional BFSMEM system

[César Pérez Álvarez]

Hola,
he conseguido aislar el problema bastante.
Si compilamos el código siguiente en un archivo, vemos como el TimeSet W se mantiene estable.

Set GenOza(Real cut)
{

Serie ser = SubSer(Gaussian(10, 1, Daily), y2006, y2008m12d31);

Serie serCut = DatCh(ser, D(If(cut == 1, cut, cut -1)), FirstS);
SetOfSerie
(

serCut

)

};

Set data = GenOza(16);
Real Ois.Store(data, "data.oza");
TimeSet W;

Si ahora cargamos el archivo data.oza, el TimeSet W se transforma en D(15).

[Víctor de Buen Remiro]

Bueno, eso arroja mucha luz sobre el asunto.

Si cambiamos la expresión en la que se crea la serie

  Serie serCut = DatCh(ser, D(If(cut == 1, cut, cut -1)), FirstS); 

por esta otra

  Serie serCut = DatCh(ser, Eval("D("<<If(cut == 1, cut, cut -1)+")"), FirstS);

ya no aparece el problema.

Como la variable "cut" no existe al cargar el OZA, el sistema no es capaz de reconstruir la expresión del fechado, mientras que en el segundo caso la la expresión a reconstruir es directamente "D(15)" que se crea sin problemas.

Lo que aún no sé es porqué en lugar de devolver el puntero NULL devuelve el objeto TimeSet W, aunque tengo la sospecha de que en algún momento alguien pidió que se devolviera el objeto por defecto cuando la expresión no es válida. Por este motivo coje al pobre W y le endosa la caché del objeto D(15) que también es almacenada para mayor eficiencia.

Aunque el problema va a poder ser resuelto por completo en unas horas, yo aconsejaría usar la expresión alternativa pues siempre es mejor manejar la expresión virtual del TimeSet.

Si la expresión no es reconstruible entonces sólo es posible manejar la caché almacenada del TimeSet, con lo que no se podría intentar extenderla posteriormente a otros periodos anteriores o posteriores al intervalo almacenado.

[Víctor de Buen Remiro]

Bueno, ya está todo aclarado. Efectivamente el problema aparece por introducir no una expresión no persistente en una forma de almacenamiento persistente. Al ser los conjuntos temporales objetos infinitos no es posible almacenarlos de forma explícita y completa: o bien se almacena implícitamente o bien se hace parcialmente. Ante la duda OIS almacena las dos cosas, la primera mediante la expresión TOL con la que se creó el objeto y la segunda como la caché entre las fechas mínima y máxima para las que el objeto haya sido consultado en le momento de ser almacenado.

Esa expresión deber ser también persistente, es decir, que debe depender sólo de constantes o variables que vayan a existir en el momento de la carga. Por ejemplo, si escribimos

#java
Set data = { Real cut=15; Include("data.oza") };

tampoco ocurrirá nada raro.

En este caso concreto la expresión es D(If(cut == 1, cut, cut -1)), y al no existir cut la expresión If(cut == 1, cut, cut -1) devuelve omitido y D(?) devuelve W, al cual se le inyecta la caché finita del objeto verdadero, que es D(15).

El problema es que esta expresión se evalua de forma transparente, sin mostrar los errores al usuairo y sin prever que de hecho la expresión puede no haber funcionado correctamente.

Yo creo que lo más prudente es que se muestren los errores para que el usuario sea consciente de que está intentando algo imposible, y que en tal caso se desestime el objeto construido y se devuelva únicamente el objeto finito creado a partir de la cache exclusivamente.

[Víctor de Buen Remiro]

(In [3527]) Fixes #1199

[Víctor de Buen Remiro]

(In [3529]) Refs #1199

[Víctor de Buen Remiro]

Ya está disponible la nueva release de windows v2.0.1 b.3 2011-05-09 18:51:45 i686-win en la que se arregla éste problema

[Víctor de Buen Remiro]

Habría que intentar evitar estas situaciones ya en tiempo de creación del OZA.

Lo ideal sería que el sistema pudiera detectar que se están usando expresiones con variables locales, y que al menos avisara de que tales expresiones no serán reconstruíbles en tiempo de carga del OZA, aunque sí la caché. Es decir, la foto seguirá funcionando tal cual pero el fechado de la serie, y por ende la serie, no serán extensibles en el tiempo más allá de sus límites actuales.

Si esto no es posible habría que prohibir, o al menos no recomendar el uso de expresiones y fomentar u obligar al uso de variables con nombre accesible globalmente bien directamente bien a través de una expresión de miembro.

[Víctor de Buen Remiro]

(In [3530]) Fixed #1199

[Víctor de Buen Remiro]

(In [3531]) Fixed #1199

[Víctor de Buen Remiro]

(In [3534]) Refs #1199

[Víctor de Buen Remiro]

(In [3535]) Refs #1199

[Víctor de Buen Remiro]

(In [3548]) Refs #1199