Roadmap

BSR must be adapted to new OOP Class of TOL v.2.0.1 in order to be more easy to use and maintain.

Most of applications of BSR models in inference and forecast tasks, and also reestimation of models to update small changes as a few new data or variables, may be treated as simulation process that could be defined as simplified versions of original and previously simulated model.

If we have an stored copy of definition and simulation results of a model and we have a simplified method to modify it in some predefined senses, then we can use BSR in a faster way to reestimate, forecast or inference tasks.

In order to reduce computational cost, user should be able to fix some parameters to specific values or skip the simulation of other ones simply by reading them from stored MCMC.

1. Fixing full blocks
2. Fixing partial blocks
3. Reloading partial Markov Chain
4. Forecasting methods by mean of missing output block

TOLBase should be updated in order to use Tk 8.5 this will provide a better native look in windows and linux.

In order to change from Tk 8.4 to Tk 8.5 we must compile BLT 3.0 because BLT 2.4z is not compatible with Tk 8.5.

BLT is the extension provinding the graphics capabilities.

In this moment TOLBase is using the BLT's version number 2.4z which has not being updated since 2002.

From BLT we are using blt::graph and blt::hiertable. There is an equivalent tree widget that is mantained from de TCT which has a better look than hiertable. This alternative tree widget is TkTreeCtrl

• Create a branch TOLBase_Tk85 for tolbase

• package require Tk 8.5

• substitute blt::hiertable for TkTreeCtrl

• compile blt 3.0 for windows and linux

• substitute blt 2.4z for blt 3.0: fix bugs related to graph

• update byswidget depending on blt::hiertable

• improve editor widget: consider TkTextPlus

All themes related to BSR API's, ASCII, Import, OneNode, DBApi, ...

Diagnosis methods for BSR about convergence of Markov Chain and quality of inference

All about BSR documentation:

1. Code inside commentaries
2. Mathematical justifications
3. User guide
4. Programmer manual
5. Courses
6. Examples of use

Definition of hierarchy and prior information over all BSR blocks

Every contrib package must have a controlled compilation process. This is necessary when changing the compiler version.

CMake seems to be a portable and multiplatform solution.

Here we should describe 3D graph capabilities of Tolbase.

Debido a la gran cantidad de trabajo ya realizado y chequeado en el lenguaje estadístico R sería un grandísimo avance para TOL disponer de una verdadera API nativa de acceso R a nivel de enlace en C++.

La idea fundamental sería poder portar en ambos sentidos los tipos de datos fundamentales, en principio números, fechas, textos, vectores, matrices y conjuntos o listas arbitrarias de esos tipos fundamentales. En cuanto a las funciones de acceso podrían ser las siguientes:

  //Inicia una sesión R enlazada desde TOL
  Real R.open(Real void);
  //Cierra una sesión R abierta anteriormente desde TOL
  Real R.close(Real sessionId);
  //Exporta una variable TOL local o global como una variable global en una sesión R abierta
  Real R.export(Real sessionId, Text Rname, Anything tolObj);
  //Devuelve el valor una variable global en R
  Anything R.import(Real sessionId, Text Rname);
  //Carga un paquete en una sesión R abierta
  Set R.require(Real sessionId, Text Rpackage);
  //Carga un fichero en una sesión R abierta
  Set R.include(Real sessionId, Text Rfile);
  //Ejecuta un código R en una sesión R abierta y devuelve el último objeto R que debe llamarse TolReturn
  Anything R.call(Real sessionId, Text Rcode);

Desde el punto de vista más "comercial" dentro de la comunidad open source tiene también todo el sentido pues se trata de dos lenguajes perfectamente complementarios, por estar R más orientado a la algoritmia académica mientras que TOL se especializa en el tratamiento masivo y en la semántica de los datos del mundo real.

Links

• RCpp: ​http://cran.r-project.org/web/packages/Rcpp/index.html
• RInside: ​http://cran.r-project.org/web/packages/RInside/index.html
• RProtoBuf: ​http://cran.r-project.org/web/packages/RProtoBuf/index.html

BSR should have a graphic interface, at least for most common DBApi tags.

Extensions of BSR to new more generic classes of models or efficient specializations of other ones.

Generic manteinance tasks of TOL

Si se conoce un método eficaz para simular cada bloque condicionado al resto entonces es aplicable el método de simulación de Gibbs tal y como se hace en BSR, pero esto implica que los bloques se tienen que conocer los unos a los otros y las reglas de condicionamiento son bastante complicadas de implementar de una forma completamente genérica, por lo que es complicado extender la clase de modelos.

Normalmente resulta mucho más sencillo evaluar la función de log-verosimilitud salvo constante condicionada al resto de bloques, lo cual permite aplicar el método Metropolis Within Gibbs, que consiste en simular alternativamente los distintos bloques con el método de Metropolis-Hastigs (MH) o alguno similar como el Multiple Try Metroplis (MTM), dejando invariantes todos aquellos de los que depende. Este esquema tiene la ventaja de que sirve para simular cualquier clase de modelos implementando bloques de simulación para cada tipo de elemento que intervenga y definiendo aparte las relaciones de condicionamiento como meras reglas de asignación total o parcial de miembros de un bloque condicionado en función de los miembros del bloque condicionante. Si para un bloque concreto se dispone de un método de generación condicionada que resulte más sencillo o eficaz que el MH o sus derivados, es perfectamente lícito aplicarlo siempre y cuando se respeten las relaciones de condicionamiento.

Currently, TOL have a good collection of GSL and AlgLib scalar univariate interpolation methods but no one on higher dimensions. A good bidimensional method is specially required, although methods on higher dimensions will be also wellcome. AlgLib has methods which uses bidimensional splines. Other important class of methods are meshless interpolation.

En el pasado existieron una serie de funciones TOL (Table, Chart, Show) capaces de mostrar gráficamente ciertos tipos de objetos TOL como conjuntos de series, matrices, etc.

Todos ellos han dejado de funcionar desde hace tiempo, no sé muy bien porqué, pero realmente tampoco es que fueran demasiado útiles porque, aparte de no permitir demasiada variedad de presentaciones, luego había que configurarlos a mano si no te servía cómo eran presentados por defecto, con lo cual no se avanzaba mucho.

Los nuevos métodos tendrían que permitir especificar no sólo los datos brutos a dibujar o tabular, sino también los títulos, anotaciones, tipos de letra, colores, estilo y formas de líneas, barras, etc; y todo aquello que conforma la configuración de la presentación.

Las nuevas capacidades OOP del lenguaje animan a hacer que sea el propio TOL el que gestione la creación, configuración y manejo de los gráficos, tablas y sistemas de representación en general mediante una jerarquía de clases que almacene y organice los datos del objeto a representar de la forma más abstracta posible y sólo en último término llame a métodos TCL, o lo que toque si algún día tenemos otros interfaces (Java, VBTOL, etc). Esto nos haría más independientes del motor de presentación y nos permitiría mayor facilidad de transición a nuevos sistemas.

Según el enfoque OOP se debería representar el objeto gráfico como una clase con los miembros adecuados para configurar todo lo necesario y los métodos de visualización y modificación necesarios. Debería haber una clase raíz que tenga exclusivamente los métodos virtuales puros comunes a todos los tipos de presentación gráfica y luego ir derivando de formajerárquica clases especializadas en dibujar o tabular los diferentes tipos.

Por supuesto que esto no implica renunciar a la posibilidad de invocar los métodos manualmente desde el inspector de objetos, pero, una vez programado en TOL el sistema sería trivial llamarlo desde el interfaz TCL usando los parámetros por defecto necesarios para todo aquello que no quede especificado por los propios elementos (series, matrices, conjuntos, ...).

Además de los típicos gráficos de series y matrices bidimensionales habría que abordar al menos gráficos 3D y de densidad, curvas isométricas, etc.

Numerical methods used in optimization, system solving, matrix decomposition, ARIMA evaluation, BSR, etc.

Implementation of OOP (Objected Oriented Programation) in TOL as is described in TolOop

Decimos que un proceso de segundo orden es periódicamente correlacionado con período si sus dos primeros momentos son funciones periódicas de período :

si el período entonces tenemos un proceso estacionario de segundo orden.

Una clase importante de modelos para describir tales periodicidades en la media y las covarianzas es la clase de modelos autoregresivos y medias móviles periódicos (PARMA). Los modelos PARMA son una extension de los modelos ARMA en el sentido de que admiten una representación de los parámetros del modelo variable en el tiempo.

Esta clase de modelos aparece con frecuencia en áreas donde las observaciones manifiestan comportamientos periódicos en las medias, varianzas y covarianzas, por ejemplo: hidrología, economía, consumo eléctrico, climatología y consumo de medios de prensa (Bayes).

Un proceso periódico estacionario con periodo sigue un modelo PARMA con período y parámetros en la estación (season) :

1. 
2. media
3. polinomio AR de grado
4. polinomio MA de grado
5. varianza

denotado por si existe un proceso tal que:

y el proceso satisface la ecuacion en diferencias:

Este milestone es el punto de arranque para definir tickets asociados a los modelos PARMA. Estos tickets caen en diferentes categorías:

1. Especificación de proceso PARMA en TOL.
2. Evaluación de modelos PARMA y generación de procesos PARMA
3. Evaluación de la verosimilitud de un proceso PARMA
4. Estimación máximo-verosimil de parámetros para un proceso PARMA.
5. Simulación de la distribución condicional completa de los parámetros de un proceso PARMA.
6. Mecanismos de diagnosis para un proceso PARMA.

Kalman filters, Bayesian filters, ...

The current growth in TOL kernel and StdLib is unmantenible and must have a standardized form to be extended with extern add-on's.

1. Modularity in TOL: In order to allow a big growning of libraries written in TOL it's neccessary to count with a well designed structure of modular development
2. LoadDynLib: A protocol for defining C++ built-in TOL entities over dynamic link libraries (.so, .dll) and an automatic cross-platform loading system which will be called from TOL.
3. Ois: Must be adapted to be used with remote URL
4. TOL parallel: Extensions for shared and distributed memory
5. TOL ++: a port from TOL to C++ to get faster code

In order to allow a big growning of libraries written in TOL it's neccessary to count with a well designed structure of modular development. See more on TolPkg

En este apartado se tratarán técnicas y trucos útiles en modelación

• Escalado de variables
• Análisis de Intervención Automática
• Ciclos deterministas (Fourier)
• Inputs no lineales
• ...