# Different declarations of variables and parameters

Dear all,
Gali5C.mod (3.7 KB)
Gali5C1.mod (1.7 KB)

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?

Kind regards,
Jose

They yield different results, because you provide different initial and terminal conditions in the initval-block

Gali5C1.mod (2.5 KB)
Gali5C2.mod (2.9 KB)
Dear Johannes Pfeifer,

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.

Thanking you in advance and best regards,
Jose

You deleted the equation tag responsible for defining the occasionally binding constraint:

[name='FOC w.r.t. to i',mcp='i>0']


The FOC is simply derived by taking the derivative with respect to the nominal interest rate. The mcp tag then defines the zero lower bound.

Dear Johannes Pfeifer,

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.

Thanking you in advance and best regards,
Jose

Please carefully read the note at the beginning of my mod-file. It already answers most of your questions.

Thank you, Johannes Pfeifer.

Dear Johannes Pfeifer,

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.

The question is why? What does # represent?

Best regards,
Jose

Dear Jose,

Without knowing the model, have a look at Johannes’ guide to specify observation equations. You find the answer under “Remark 4” what the # sign does.

Best,

Rob

Thank you, Dear Robert.

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)?

Regards,
Jose

Define beta as a model-local variable (# operator). But in this case, it is not defined as a parameter or variable.

Gali5C2.mod (3.2 KB)

Dear Johannes Pfeifer,

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.

What am I missing?

Thanks in advance and regards,
Jose

Dear Johannes Pfeifer,

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

Dear Johannes Pfeifer,

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

Gali5C2.mod (4.3 KB)

Best regards,
Jose

1. Yes, the ordering matters as you can include previously define model-local variables in subsequent ones.
2. I would in this case recommend to use a steady_state_model-block to define the parameter dependence. See e.g. https://github.com/JohannesPfeifer/DSGE_mod/blob/master/Gali_2015/Gali_2015_chapter_6_4.mod

Dear Johannes Pfeifer,

1- Noted. I appreciate.

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.

Gali5C2.mod (4.4 KB)

Thank you for your time and patience,
Jose

1. The latest parameters are always stored in M_.params, not in the workspace!
2. 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.

Gali5C2.mod (4.3 KB)

Dear Johannes Pfeifer,

Thank you.

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?

Best regards,
Jose

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.