Testeo de informacion a priori coherente: Comprobación de combinaciones lineales

[lmperez]

Comprobar si existe alguna combinación lineal entre parámetros de un nodo observacional, teniendo en cuenta si éste tiene o no una distribución a priori y/o está dentro de una jerarquía. Y además debe informar cuál es la combinación lineal.

Se adjuntan funciones.tol​ las siete funciones que hacen este proceso en BSRLayer, una llama a las otras, pero usan sets de información que no existen en MMS, si decidís usarlas como guía preguntadme cualquier duda que tengáis.
Al final, si detecta una combinación lineal, escribe los parámetros que la forman en un fichero log, en forma de query.

Una cosa a tener en cuenta. El proceso en general funcionaba en torno a la función SVD de tol, sin embargo, como esta función no es exacta sino aproximada, se probaron los diferentes métodos: Golub_Reinsch, Jacobi y Sparse. De todos ellos, el más fiable fué el primero. El Sparse era muy rápido cuando las matrices a factorizar tenían densidades pequeñas (<0.01), y el Jacobi mostraba una salto de nivel muy claro entre los autovalores de las variables que no son combinaciones lineales de los que sí lo son. Sin embargo éstos dos últimos fallaban a veces, detectando combinaciones lineales donde no las había o al revés. Por defecto se decidió usar Golub_Reinsch con un redondeo en 10-10.

[lmperez]

Se ha vuelto a solicitar la necesidad de tener una herramienta para
testear los inputs: #122.

[irobles]

Buenos días,

lo de las combinaciones lineales, en algunos proyectos hemos estado haciendo alguna cosa para ir comprobandolas, pues ahora mismo el unico error que da es el de CholeskiSolve, y hemos estado haciendo alguna cosa para que nos indique cuales son los inputs problematicos, pero al final el problema es que cada proyecto tendra sus funciones, por eso pedimos que esten centralizadas en MMS.

Si quereis os puedo poner ejemplos de funciones que son las que ha puesto Luis arriba pero adaptadas a MMS, por si os sirven de ayuda. Si es asi pedirmelas.

De todas formas como entiendo que tener bien controladas las combinaciones lineales es un trabajo que puede ser complicado, lo que si os pido es que nos vayais faciltando comprobaciones como la indicada en el ticket 122.

Lo recuerdo aqui

Cuando un input es nulo o no está definido en el rango temporal de un
output al estimarlo devuelve un error de combinación lineal. Se podría
incorporar un proceso chequease los inputs y eliminase estas
posibilidades?

También indicar que lo indicado arriba muchas veces nos pasa a los analistas al meter un input y despues diferenciarlo, o retardarlo. Si nos da un mensaje de Warning diciendo cual es el input problematico nos ayudaria mucho.

Gracias

[Pedro Gea]

(In [1866]) Se implementan métodos de "test" para algunos objetos del módulo de modelos:

• Un test de independencia de un parámetro (un m-elemento en general) que nos permite saber si tiene asociada información a priori (un prior o una jerarquía). El método ::TestIndependence devuelve 1 si es independiente (no tiene información a priori) y 0 en otro caso.
• Un test de regularidad de un término explicativo que nos permite saber si un término explicativo es válido para la estimación. El método ::TestRegularity devuelve 1 si el término es regular y 0 si es completamente singular. El test se realiza para cada subtérmino lineal de modo que un término explicativo de tipo omega devuelve el promedio de los test para sus parámetros lineales (con sus subinputs retardados convenientemente). Un término es regular (=1.0) sólo si todos sus subtérminos lo son.

Refs #122, #79

[mafernandez]

(In [1923]) Refs #79

Se introduce el método CheckMulticollinearity en la clase @Submodel. Mediante el algoritmo SVD se determinará que inputs correlacionan a nivel de submodelo.

[Pedro Gea]

(In [1943]) Se amplía el método de chequeo de la multicolinealidad para submodelos con matrices.
Se modifica la función SVDProcedure para usar la matriz cuadrada A'A en lugar de AA'.
Refs #79

[Pedro Gea]

Véase también el problema de multicolinealidad que plantea #428.

[Pedro Gea]

Véase #534

[Pedro Gea]

Véase: Multicollinearity

[Pedro Gea]

(In [2366]) Se modifican dos métodos de acuerdo a los convenios descritos en #553.
El método Real <mObjectPrior>::TestRegularity() pasa a llamarse Real <mObjectPrior>::IsIndependent().
El método Real <expTerm>::TestRegularity() pasa a Set <expTerm>::CheckRegularity(showMode) y se crea un Set <submodel>::CheckExpTerms.Regularity(showMode) con un estilo similar a los métodos CheckConstraint y CheckMCombinations.Constraint.
El método {{CheckExpTerms.Regularity}}} es un mecanismo alternativo aCheckMulticollinearity para detectar los parámetros cuyo input es nulo.
Provisionalmente se dejan versiones obsoletas advirtiendo de su desaparición.
Refs #553, #79