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 13 years ago

Closed 13 years ago

#1536 closed defect (fixed)

duda sobre warning en BTmsDifference::Successor

Reported by: Jorge Owned by: Víctor de Buen Remiro
Priority: normal Milestone: Mantainance
Component: TimeAlgebra Version: 3.1
Severity: normal Keywords:
Cc:

Description

Al ejecutar el código adjunto se genera el siguiente warning:

Warning: [1] BTmsDifference::Successor has been aborted because it has fall out of calculation range  operating between dates y2012m05d09,y2040m05d20]
Probably this is an expression of empty time set.

No me queda claro por qué se emite ese mensaje si despues del y2012m05d09 ya no hay que buscar nada más.

Attachments (2)

mib diario.xls (111.5 KB) - added by Jorge 13 years ago.
cargar_mib_diario.tol (1.4 KB) - added by Jorge 13 years ago.

Download all attachments as: .zip

Change History (12)

Changed 13 years ago by Jorge

Attachment: mib diario.xls added

Changed 13 years ago by Jorge

Attachment: cargar_mib_diario.tol added

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

Tú sabes que no hay que buscar más pero el sistema no lo sabe.

Copio el trozo de código que nos interesa

Serie unknownAt = IsUnknown( mib_diario );
TimeSet unknownTS   = SerTms( unknownAt );
Serie mib_diario_kn = DatCh( mib_diario, C - unknownTS,FirstS);

El conjunto temporal C - unknownTS es finito porque unknownTS coincide con C donde la serie unknownAt no es nula, y como se trata de una serie finita fuera de sus fechas es desconocida por lo que no se puede asegurar que sea nula y se toma por congruencia que no lo es.

La función DatCh al tratar de buscar la fecha inicial del resultado tiene que encontrar la primera fecha de C - unknownTS no posterior a la fecha inicial de mib_diario que es 2004-01-01 pero resulta que no existe ninguna fecha en C - unknownTS anterior o igual a esa, por lo que al cabo de unos miles de iteraciones se da por vencido e induce heurísticamente que podría tratarse de un conjunto acotado y para el proceso para no caer en un ciclo infinito.

Lo que sí he encontrado es un error en los límites de SerTms. En un principio esta función estaba pensada para series infinitas pero luego se admitió que fueran finitas con el criterio de que fuera del rango de fechas de la serie no estuviera definido el conjunto temporal. Más tarde se observó que si la serie tenía omitidos por el centro para ser coherente ese criterio debería tomar los omitidos como valores cero lo cual era incompatible con el comportamiento de otras funciones, por lo que se tomó el omitido como no nulo, tanto dentro como fuera del intervalo de fechas. Sin embargo no se tuvo en cuenta que los métodos BTmsOfSerie::CalcInf() y BTmsOfSerie::CalcSup() debían retornar ahora el inicio y el final de los tiempos dando lugar a ciertas incohrencias como que

  Set Dates(C - unknownTS, y2000, y2020); 

esté devolviendo fechas sólo entre los límites de mib_diario

Sin embargo, el visor de calendarios de TOLBase, como no hace uso de esos métodos funciona correctamente y da por buenas todas las fechas fuera de ese rango.

Así pues, aunque el ticket en principio no expresa nada que esté mal sí ha servido para encontrar otro problema relacionado.

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

(In [4691]) Refs #1536

comment:3 Changed 13 years ago by Víctor de Buen Remiro

Resolution: fixed
Status: newclosed

comment:4 Changed 13 years ago by Víctor de Buen Remiro

(In [4692]) Refs #1536

comment:5 Changed 13 years ago by Víctor de Buen Remiro

Resolution: fixed
Status: closedreopened

Los últimos cambios son incompatibles con los tickets #354 y #457

Hay que aclarar que cosas se le pueden pedir a SerTms pues está claro que se le piden cosas incompatibles entre sí.

Tal y como estaba antes de estos cambios el SerTms de una serie finita se comporta según un conjunto acotado o no acotado según la función que se use, lo cual es absurdo.

Ahora mismo siempre se comporta como no acotado de forma que no da problemas importantes al actuar como fechado.

Si se quiere que sea compatible con #354 y #457 entonces debería ser acotado siempre y no sé las consecuencias que podría tener.

comment:6 Changed 13 years ago by Víctor de Buen Remiro

(In [4816]) Refs #1536
Refs #354

comment:7 Changed 13 years ago by Víctor de Buen Remiro

(In [4817]) Refs #1536
Refs #457

comment:8 Changed 13 years ago by Víctor de Buen Remiro

(In [4818]) Refs #1536
Refs #457

comment:9 Changed 13 years ago by Víctor de Buen Remiro

(In [4819]) Refs #1536
Refs #354

comment:10 Changed 13 years ago by Víctor de Buen Remiro

Resolution: fixed
Status: reopenedclosed

(In [4820]) Fixes #1536 in 3.1

Note: See TracTickets for help on using tickets.