Re: [DynareDev] SWZ Question regarding max_lag_length r
Hi Houtan,
Dear Michel and Sébastien,
Everything is coded and tested for the svar_identification. However, I want to check my implementation of the maximum lag length (r) with you. In order to obtain r, I have introduced a temporary variable entitled max_endo_lag in ParsingDriver, which updates this variable every time add_model_variable() is called. Is this the best way to do this or can you think of a better way. I should point out that it is my understanding that the variables entitled like max_endo_lag in DynamicModel do not actually contain the original maximum endogenous lag in the model (which is what I understand should be the value for r). Otherwise, I would have simply included dynamic_model in the SvarIdentificationStatement class.
this is true. (S)VAR will be the only type of models that are left with lags on more than one period.
One problem with the implementation I have chosen is that we would need to ensure that the model block is declared before the svar_identification block in the .mod file. I noticed that, currently, though in the manual we are instructed as to the proper declaration order within the .mod file (i.e. vars, params, model, ..., estimation/stoch_simul), this order is not enforced within Dynare.
In fact, certain mixes of this ordering work (e.g. putting the initval statement above the model block) whereas certain orderings fail without any sort of descriptive message (e.g., ... shock block, initval block, model block ...). In my opinion, enforcing some sort of ordering and exiting with a warning to the user would be nicer than simply allowing dynare to crash.
So, if the implementation described in paragraph 1 that obtains the maximum endogenous variable lag length by constantly updating this variable in add_model_variable is correct, we must ensure that the model block has been declared before the svar_identification block so that this variable will have been set. That said, I welcome any ideas that would solve this problem more efficiently than the method described herein. They are in fact very few strict order dependencies that need to be enforced and checked. The manual gives more an advice than an obligation.
For, (S)VAR, we don't need the model block and we need to relax this requirement in the preprocessor. In this particular case, I don't think that we need to enforce any consistency. It makes sense for example to declare identification restrictions on many lags and then decide to estimate with a smaller number of lags in the VAR, without asking the user to adjust the SVAR_IDENTIFICATION block. You probably need to create an SvarIdentificationStatement class similar to i.e. InitParamStatement in NumericalInitialization.hh that record all the identification restrictions before the output stage. You can declare there a private variable with the maximum number of lags used in the svar_identification block. Sebastien, what do you think? Best Michel You need however the maximum number of lags used in the SVAR_IDENTIFICATION block to dimension Ri
Le vendredi 04 décembre 2009 à 09:05 +0100, Michel Juillard a écrit :
Hi Houtan,
Dear Michel and Sébastien,
Everything is coded and tested for the svar_identification. However, I want to check my implementation of the maximum lag length (r) with you. In order to obtain r, I have introduced a temporary variable entitled max_endo_lag in ParsingDriver, which updates this variable every time add_model_variable() is called. Is this the best way to do this or can you think of a better way. I should point out that it is my understanding that the variables entitled like max_endo_lag in DynamicModel do not actually contain the original maximum endogenous lag in the model (which is what I understand should be the value for r). Otherwise, I would have simply included dynamic_model in the SvarIdentificationStatement class.
this is true. (S)VAR will be the only type of models that are left with lags on more than one period.
Actually for deterministic models we don't remove leads and lags of more than one period. Currently, the transformation is only applied for stochastic models. What I don't understand is why you rely on add_model_variable() for computing a maximum endo lag, since as Michel points it, there is no model block when doing (S)VAR... If this means that you store VariableNodes inside SvarIdentificationStatement, this is probably a bad idea: you'd better symbol ids and leads/lags directly as integers. Otherwise, to be more precise, what are you computing exactly? Since there is no model block, there is no concept of model maximum endogenous lag. If you mean the max endo lag inside the svar_identification block, then this should be computed by a method inside the SvarIdentificationStatement class, depending on when you need that information... Doing this during the parsing pass breaks the idea of clearly separating the various tasks. Sorry if I am missing something Best -- Sébastien Villemot
Hi Michel and Sébastien, The implementation I had chosen for SvarIdentificationStatement (modified by the conversation regarding the maximum lag) is class SvarIdentificationStatement : public Statement { public: typedef map<pair<int, int>, vector<string> > svar_identification_exclusion_type; private: const svar_identification_exclusion_type exclusion; const bool upper_cholesky_present; const bool lower_cholesky_present; const SymbolTable &symbol_table; int get_max_lag() const; public: SvarIdentificationStatement(const svar_identification_exclusion_type &exclusion_arg, const bool &upper_cholesky_present_arg, const bool &lower_cholesky_present_arg, const SymbolTable &symbol_table_arg); virtual void writeOutput(ostream &output, const string &basename) const; }; The map above stores pair<lag number, equation number>, vector of restrictions> The vector<string> type is similar to the SymbolList type. I am not using SymbolList because this provides direct access to the vector elements for writing. I am sorry, but I do not quite see the purpose of fillEvalContext from InitParamStatement or how it would be useful in this case. Why can't I simply take the information in and then write the output as described on the Wiki? Again, I'm so terribly sorry for the confusion on this matter and for needing things explained in so much detail. Best, Houtan 2009/12/4 Sébastien Villemot <sebastien.villemot@ens.fr>
Le vendredi 04 décembre 2009 à 09:05 +0100, Michel Juillard a écrit :
Hi Houtan,
Dear Michel and Sébastien,
Everything is coded and tested for the svar_identification. However, I want to check my implementation of the maximum lag length (r) with you. In order to obtain r, I have introduced a temporary variable entitled max_endo_lag in ParsingDriver, which updates this variable every time add_model_variable() is called. Is this the best way to do this or can you think of a better way. I should point out that it is my understanding that the variables entitled like max_endo_lag in DynamicModel do not actually contain the original maximum endogenous lag in the model (which is what I understand should be the value for r). Otherwise, I would have simply included dynamic_model in the SvarIdentificationStatement class.
this is true. (S)VAR will be the only type of models that are left with lags on more than one period.
Actually for deterministic models we don't remove leads and lags of more than one period. Currently, the transformation is only applied for stochastic models.
What I don't understand is why you rely on add_model_variable() for computing a maximum endo lag, since as Michel points it, there is no model block when doing (S)VAR... If this means that you store VariableNodes inside SvarIdentificationStatement, this is probably a bad idea: you'd better symbol ids and leads/lags directly as integers.
Otherwise, to be more precise, what are you computing exactly? Since there is no model block, there is no concept of model maximum endogenous lag.
If you mean the max endo lag inside the svar_identification block, then this should be computed by a method inside the SvarIdentificationStatement class, depending on when you need that information... Doing this during the parsing pass breaks the idea of clearly separating the various tasks.
Sorry if I am missing something
Best
-- Sébastien Villemot
Le vendredi 04 décembre 2009 à 09:09 -0500, houtan a écrit :
The implementation I had chosen for SvarIdentificationStatement (modified by the conversation regarding the maximum lag) is
class SvarIdentificationStatement : public Statement { public: typedef map<pair<int, int>, vector<string> > svar_identification_exclusion_type; private: const svar_identification_exclusion_type exclusion; const bool upper_cholesky_present; const bool lower_cholesky_present; const SymbolTable &symbol_table; int get_max_lag() const; public: SvarIdentificationStatement(const svar_identification_exclusion_type &exclusion_arg, const bool &upper_cholesky_present_arg, const bool &lower_cholesky_present_arg, const SymbolTable &symbol_table_arg); virtual void writeOutput(ostream &output, const string &basename) const; };
This looks good. When you're done, don't forget to add comments using Doxygen style (with the exclamation mark).
The map above stores pair<lag number, equation number>, vector of restrictions>
The vector<string> type is similar to the SymbolList type. I am not using SymbolList because this provides direct access to the vector elements for writing.
I am sorry, but I do not quite see the purpose of fillEvalContext from InitParamStatement or how it would be useful in this case. Why can't I simply take the information in and then write the output as described on the Wiki?
You don't need to implement that method. It is used for assigning numeric values to variables, so it has no sense here. Best -- Sébastien Villemot
One final question. Should syntax such as this be allowed: exclusion lag 0; equation 1, pie, r; exclusion lag 0; equation 2, y; (i.e. lags are repeated but equation numbers are different) or should we declare a user error. I am already declaring an error when something such as this is encountered: exclusion lag 0; equation 1, pie, r; exclusion lag 0; equation 1, pie, r; (i.e. lags and equation numbers overlap) 2009/12/4 Sébastien Villemot <sebastien.villemot@ens.fr>
Le vendredi 04 décembre 2009 à 09:09 -0500, houtan a écrit :
The implementation I had chosen for SvarIdentificationStatement (modified by the conversation regarding the maximum lag) is
class SvarIdentificationStatement : public Statement { public: typedef map<pair<int, int>, vector<string> > svar_identification_exclusion_type; private: const svar_identification_exclusion_type exclusion; const bool upper_cholesky_present; const bool lower_cholesky_present; const SymbolTable &symbol_table; int get_max_lag() const; public: SvarIdentificationStatement(const svar_identification_exclusion_type &exclusion_arg, const bool &upper_cholesky_present_arg, const bool &lower_cholesky_present_arg, const SymbolTable &symbol_table_arg); virtual void writeOutput(ostream &output, const string &basename) const; };
This looks good. When you're done, don't forget to add comments using Doxygen style (with the exclamation mark).
The map above stores pair<lag number, equation number>, vector of restrictions>
The vector<string> type is similar to the SymbolList type. I am not using SymbolList because this provides direct access to the vector elements for writing.
I am sorry, but I do not quite see the purpose of fillEvalContext from InitParamStatement or how it would be useful in this case. Why can't I simply take the information in and then write the output as described on the Wiki?
You don't need to implement that method. It is used for assigning numeric values to variables, so it has no sense here.
Best
-- Sébastien Villemot
_______________________________________________ Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev
Le vendredi 04 décembre 2009 à 11:40 -0500, houtan a écrit :
One final question. Should syntax such as this be allowed:
exclusion lag 0; equation 1, pie, r; exclusion lag 0; equation 2, y;
(i.e. lags are repeated but equation numbers are different) or should we declare a user error. I am already declaring an error when something such as this is encountered:
exclusion lag 0; equation 1, pie, r; exclusion lag 0; equation 1, pie, r;
(i.e. lags and equation numbers overlap)
For consistency with the rule about equation, we should make an error when there are several exclusion blocks for a given lags (so fail on your two examples) -- Sébastien Villemot
participants (3)
-
houtan -
Michel Juillard -
Sébastien Villemot