Please see attached files. When running them one arrives at different results, when, as far I know, they are quite similar. Indeed the second file tries to replicate the first, which appears to be the correct one.
The key difference lays on the declaration of variables. In Gali5C1 variables are defined in a standard way, such as var pi…
In Gali5C the same variable is declared as var pi ${ \pi } (long_name = ‘inflation’)
The question, thus, is why the two scripts yield different results?
Your reply could not be more straightforward. Thank you.
However I am still flabbergasted. After a thorough revision, I continue to be confronted with different results using identical initial and terminal conditions.
Reading the Dynare manual, I noticed that caution should be taken when writing parameters (eg alpha vs. alppha), but no reference is made to possible different specifications of variables (other than eg i or pi), as you did when replicating Gali’s (2015) figure 5.3. This was the reason for creating this new topic.
Most likely this is due to a mistake of mine, untraceable for my eyes. I checked it over and over along with another person to no avail. In another script, which extends the present one with additional equations, I ended up with similar results in respect to the output gap and inflation; they are pinned down to zero right from inception. Is it there a remote possibility of a bug in the Dynare software?
On another subject, I could not quite understand how you arrive in your script (figure 5.3 under commitment) at the first order condition wrt to the nominal interest rate; specifically, you write down xi_2*1/sigma = 0.
Thanks. I gather that the “mcp” tag is a built-in command requiring the specification that you mention above. Is “mcp” an acronym for mixed complementarity problem?
Looking again at your replication of figure 5.3, I understand that in order to set some (i and rn) initial and terminal conditions at 2% (annualized and considering beta = 0.995) , you define i as the nominal interest rate, while id = i - rn (the natural interest rate). In order to meet these initial and terminal conditions, id should enter other standard equations, such as a money demand function, while a Taylor rule should take the form i = max (0, psi*pip + rn). I am sorry for imposing on you, but your insights have been very helpful.
Returning back to your script, I notice that you include in the model component, the definition of the parameters Omega, lambda, kappa, and vartheta (all functions of theta) preceded by the symbol # . Moreover, you do not list these parameters either under the variables or under the parameters sections, the exception being theta. I moved these parameters into the parameters area and arrived at the same results.
Extending your script to allow for deterministic shocks to theta I found out that in order to arrive at a perfect foresight solution (a reasonable and expected one) and the rank condition satisfied, I had to rely on your specifications.
Gali5C2.mod (3.1 KB)
Dear Robert or Johannes Pfeifer or…
Please find attached for ease of reference, a script based on Johannes Pfeifer replication of Gali´s (2015) figure 5.3.
In this script, beta (the discount factor) is specified as a parameter. The natural rate of interest (r_nat) is treated as an exogenous variable (varexo) and is submitted to a negative deterministic shock. The model runs fine.
However beta and r_nat are tied together as follows: r_nat = 100*(1-beta)/beta. I tried to establish this association by inserting this equation into the model section preceded by the symbol #. I was confronted by an error message:
“Variable beta not allowed inside model declaration. Its scope is only outside model.”
Additionally, I considered beta as a varexo and defined initial and terminal values, as well as intermediate values, consistent with those set for r_nat (up to four decimal points). This also led to an error message.
The question, thus, is there anyway to set this interdependence of these two parameters (variables)?
I am sorry, but it did not work out and the following error message came out:
" r_nat has wrong type or was already used on the right-hand side. You cannot use it on the left-hand side of a pound (’#’) expression."
The attached revised script shows that beta has been defined as a model-local variable expressed as a function of the natural rate (please see lines 60 and 58 in the script), which is specified as a varexo and is subject to a negative deterministic shock. My expectation was that a shock to the natural rate would filter through other model-local variables such as beta and kappa, and so forth in the model section.
I did not receive your feed-back to my previous message two days ago.
In the meantime, the error message was overcome by merely moving to the first line beta as a function of r_nat preceded by #. The results appear to be correcThis suggests that the ordering of the model-local variables has a bearing on the outcome. Am I correct?
Another issue is how to retrieve these variable parameters
The message was interrupted and an unfinished reply was sent to you…
The other issue is how to retrieve these variable parameters. I was only able to arrive at the values, say of beta, indirectly by using the NKPC which by the way, proved to exhibit the expected values. Any suggestions?
For ease of reference, please see attached the a revised script
2- Thank you for sharing your script. It is far complex in terms of codes for my limited knowledge of Dynare. I notice however, that the variable parameters including those in the steady state model block do not appear in the workspace. The objective here is to retrieve the variable parameters, isn’t it?
3- Anyway, I tried to replicate your steady state block by considering kappa and vartheta (lines 67 and 69), which were transferred to a model block (lines 123 to 130). It did not work out, as both kappa and vartheta became unknown symbols. What am I doing wrong?
4- In order to, eventually, facilitate your analysis, please see the attached file.
The latest parameters are always stored in M_.params, not in the workspace!
You need to move all model-local variables into parameters as the definitions are recursive and only moving the last two to parameters implies that components like Omega are unknown in the steady_state_model-block. See the attachement.
The “variable parameters” do appear in terms of steady state in M_.params; however their paths are not retrieved. For instance, beta equals 0.995 1.005…0.995…Is it there any solution to capture these dynamics, other than using the relevant equations?
I am not sure I understand. There is no such thing as
A parameter is a fixed number. What you have in mind is making beta a variable. But that turns everything depending on beta into a variable as well. This conflicts with the linearization that assumes beta to be a parameter. Essentially, the variable beta and the steady state discount rate are two different objects.