close Warning: Can't synchronize with repository "(default)" (/var/svn/mms does not appear to be a Subversion repository.). Look in the Trac log for more information.

Opened 13 years ago

Closed 12 years ago

#856 closed task (fixed)

La evaluación de variables con pseudo-expresión TOL debería cachearse

Reported by: vdebuen Owned by: Pedro Gea
Priority: critical Milestone: Development 1A
Component: Variables Keywords:
Cc:

Description

La evaluación de variables con pseudo-expresión TOL con argumentos del tipo %1,%2,... debería cachearse internamente para no realizarse más que una vez por sesión. O al menos debería existir la opción de hacerlo así y que la gente sea consciente de los riesgos que supone.

Por una parte, si la expresión conlleva mucho tiempo de cálculo ahorraremos tiempo de ejecución, pero aún es más grave si la expresión no es determinista, porque entonces puede dar lugar a incongruencias graves.

Por ejemplo, en PRCOCO estamos creando un objeto modelo probit para lanzarlo varias veces de forma que en cada sesión se genere un output distinto en base a cierto prior beta truncado para evitar un problema de censura en los datos output. Para evitar crear N objetos distintos, estamos usando una expresión del tipo citado.

Sin embargo, al ejecutarlo, en una misma sesión observo que se ha ejecutado 5 veces esa función que muestra una traza a tal efecto. No sé exactamente porque se llama tantas veces pero entiendo que puede ser razonable. De hecho en BSR el output ya entra en dos sitios: el master y el filtro probit. Y ahí es donde viene el verdadero problema pues al venir de dos llamadas distintas se trata de dos matrices distintas que deberían ser la misma y el modelo es incongruente.

Por el momento yo me voy a cachear esa función dando por supuesto que sólo se llama una vez por sesión pero eso debería arreglarse en MMS si se puede, o bien abandonar el uso de este tipo de expresiones por el extremo peligro que supone.

Change History (3)

comment:1 Changed 13 years ago by Pedro Gea

Milestone: MaintenanceRelease 0.6
Priority: blockercritical
Type: defecttask
version: 0.6

Como muchas cosas, esto tiene sus ventajas e inconvenientes. Las principales ventajas son:

  • reducir el uso de memoria evitando cachear lo que no es imprescidible y
  • permitir la actualización de las variables en la simulación de escenarios, facilitando que los cambios en las variables originales (drivers) repercutan sobre otras variables calculadas a partir de éstas.

En cualquier caso lo reconsideraremos e intentaremos darle la mayor versatilidad a estos mecanismos.

La cuestión de que la expresión de una variable dependiente no sea determinista me parece una cosa más bien intolerable, pero supongo que sus razones tendrá.

comment:2 Changed 13 years ago by Pedro Gea

Milestone: Release 0.6Development 1A
version: 0.61

Algunas de estas cuestiones se están tratando de manera distinta en la nueva versión de MMS.

comment:3 Changed 12 years ago by Pedro Gea

Resolution: fixed
Status: newclosed

Véase #957.

Note: See TracTickets for help on using tickets.