Salut Michel,
Je comprends maintenant mieux le problème avec varexo.
La classe VariableTable maintient la liste des variables dynamiques, c'est à dire soit des triplets (symbol_type, symbol_id, lead/lag) pour tous les types de variables (endo, exo, exodet)
Elle attribue un numéro à ce triplet lors du parsing de la variable dans le modèle (numéro noté var_id), attribué dans l'ordre d'apparition lors du parsing. Ce numéro est utilisé en interne dans ModelTree pour faire les dérivations.
Après avoir parsé et fait les dérivations, on appelle la méthode VariableTable::sort() qui va classer ces triplets par ordre lexicographique et donner les nouveaux numéros associés, qu'on appellera des sort_id (la méthode n'a en fait pas besoin de faire le tri, car la structure C++ qui stocke les triplets a déjà fait ce tri, donc il suffit juste de lire les triplets dans l'ordre dans lequel ils sont stockés).
C'est le sort_id (qu'on récupère avec VariableTable::getSortID()) qui est utilisé pour déterminer la colonne du jacobien; la matrice d'incidence donne le mapping entre ce sort_id et le couple (symbol_id, lead/lag), mais *uniquement pour les endogènes*.
Si je comprends bien, le code Matlab suppose qu'après les colonnes des endogènes, apparaissent les colonnes des exogènes puis des exogènes déterministes, en supposant que chaque symbole occupe exactement une colonne, et dans l'ordre de déclaration de varexo ou varexo_det
Dans l'état actuel du code, le préprocesseur ne donnera pas ce qu'attend le code Matlab dans les deux situations suivantes: * si une variable exogène n'est pas déclarée, comme dans ton exemple; le code Matlab attend une colonne qu'il n'utilisera jamais (ou peut-être qu'il l'attend remplie de zéros), tandis que le préprocesseur va omettre cette colonne * si une variable exogène est utilisée avec un lead/lag, ce qui n'est pas interdit (cela va juste faire un warning); dans ce cas le préprocesseur va au contraire ajouter une colonne non désirée
On peut facilement résoudre le premier problème avec la solution que tu as proposée, mais je la mettrais plutôt dans VariableTable::getSortID(). Je peux m'en occuper.
Pour le cas d'une exogène avec lead/lag, la solution me semble moins évidente, car je comprends mal comment on doit rendre les dérivées dans ce cas.
Amitiés
Sébastien
Le samedi 23 août 2008 à 19:28 +0200, Michel Juillard a écrit :
Salut Sébastien,
dans le répertoire juillard4, il y a deux fichiers *.mod, model_financial.mod et test1.mod. La seule différence est l'ordre des variables dans l'instruction VAREXO.
Dans ce modèle, il y a 125 variables dynamiques (en distinguant selon le lag). Le Jacobien par rapport aux variables exogènes commence dans la colonne 126. La variable exogène gdx est en 3e position dans model_financial.mod et en 17e position dans test1.mod. gdx apparaît dans la 55e équation et la dérivée est placée correctement dans g1(55,128) dans model_financial_dynamic.m Dans test1_dynamic.m, elle apparaît de manière erronnée dans g1(55,140) et non g1(55,142)
Le problème apparaît lorsqu'il y a des variables exogènes déclarées, mais qui ne sont pas utilisées dans le modèle. Dans ce cas elles ne sont pas dans variable_table.
Je t'écris ou t'appelle plus tard, car je crois que j'ai une solution.
amitiés
Michel