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
Grand merci. C'est exactement le problème. Corrige 1) stp, en modifiant VariableTable.getSortID() Pour 2), leads et lags ne sont autorisés que dans les modèles déterministes et, dans ce cas, nous n'avons pas besoin des dérivées par rapport aux variables exogènes. Si des leads(lags) sont présents dans un modèle et qu'on utilise une technique stochastique, il faudrait une erreur plutôt qu'un warning.
Peux-tu me dire quand tu peux faire la modification, pour que je puisse informer Christiano.
Merci d'avance et bien amicalement,
Michel
Sébastien Villemot wrote:
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
Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev
J'ai normalement fixé le bug que tu m'as signalé. Je te laisse recompiler le préprocesseur et vérifier que ça corrige effectivement le problème.
Pour la question des exogènes avec lead/lags, je transformerai le warning en erreur un peu plus tard.
Amitiés
Sébastien
Le dimanche 24 août 2008 à 10:25 +0200, Michel Juillard a écrit :
Grand merci. C'est exactement le problème. Corrige 1) stp, en modifiant VariableTable.getSortID() Pour 2), leads et lags ne sont autorisés que dans les modèles déterministes et, dans ce cas, nous n'avons pas besoin des dérivées par rapport aux variables exogènes. Si des leads(lags) sont présents dans un modèle et qu'on utilise une technique stochastique, il faudrait une erreur plutôt qu'un warning.
Peux-tu me dire quand tu peux faire la modification, pour que je puisse informer Christiano.
Merci d'avance et bien amicalement,
Michel
Sébastien Villemot wrote:
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
Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev
Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev
Grand merci
Michel
Sébastien Villemot wrote:
J'ai normalement fixé le bug que tu m'as signalé. Je te laisse recompiler le préprocesseur et vérifier que ça corrige effectivement le problème.
Pour la question des exogènes avec lead/lags, je transformerai le warning en erreur un peu plus tard.
Amitiés
Sébastien
Le dimanche 24 août 2008 à 10:25 +0200, Michel Juillard a écrit :
Grand merci. C'est exactement le problème. Corrige 1) stp, en modifiant VariableTable.getSortID() Pour 2), leads et lags ne sont autorisés que dans les modèles déterministes et, dans ce cas, nous n'avons pas besoin des dérivées par rapport aux variables exogènes. Si des leads(lags) sont présents dans un modèle et qu'on utilise une technique stochastique, il faudrait une erreur plutôt qu'un warning.
Peux-tu me dire quand tu peux faire la modification, pour que je puisse informer Christiano.
Merci d'avance et bien amicalement,
Michel
Sébastien Villemot wrote:
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
Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev
Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev
Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev
-
Michel Juillard -
Sébastien Villemot