Hello,
I am new to dynare++ and am trying to figure out what the difference between
stoch_simu(order = x) in dynare and order = x in dynare++, when x>1.
Specifically, I calculated the IRF for the first example in https://www.dynare.org/assets/dynare++/dynare++-tutorial.pdf
using dynare and dynare++.
It seems that the difference between dynare and dynare++ is larger than standard numerical errors, even when we only look at first-order or second-order approximation (the codes are attached). Why do they differ at a lower order?
example++order1.mod (1.0 KB) exampledynare.mod (845 Bytes)
Also, what is unique in dynare++ with order = x that stoch_simu(order=x) can not achieve?
Thank you for your help in advance!
Hi,
By default Dynare++ represents the decision rule under a slightly different form (the so-called “centralized” form, see Dynare++ tutorial section 4.1), which results in small numerical discrepancies. If you want to get exactly the same results as Dynare, add the --no-centralize option to Dynare++.
Otherwise the two software use the same codebase and do the same thing. Currently, Dynare++ has only two features that Dynare does not have: the centralization mentioned above, and more significantly the ability to compute the approximation around the so-called “stochastic fix point” (see section 4.2 of the Dynare++ tutorial).
We plan to retire Dynare++ at some point in the future, once we have satisfactorily implemented the stochastic fix point feature in Dynare. So we discourage the use of Dynare++ for new work, unless you really need the features that are not present in plain Dynare.
I forgot to mention that Dynare++ has another feature not present in Dynare: the ability to compute approximation errors (also called Euler errors) of the approximated decision rule (see section 4.4 of the Dynare++ tutorial).
Thank you for your detailed response.
I just tried the
dynare++ --no-centralize example++order1.mod
example++order1.mod (1.0 KB) and it generates the same results as
dynare++ --centralize example++order1.mod.
And I have tested the difference for different x in order = x and the two commands seem to generate the same results.
More over, when I look at the IRF of dyn_irfp_EPS_mean(dyn_i_K,:), the results from dynare++ are roughly 20% lower than the one generated by the dynare exampledynare.mod (845 Bytes)
Do you happen to know why these two methods have the same results in this case? Thanks!
Note that it’s perfectly normal that --no-centralize and --centralize generate the same results. This is the expected behaviour, see the Dynare++ tutorial. There are still tiny numerical differences between the two, due to numerical approximation errors. Also note that if you pass --no-centralize to Dynare++, you will get exactly the same policy function as in Dynare.
Regarding the rather large numerical differences between the IRFs, you are perfectly right, and it took me some time to figure out why.
This comes from the fact that the exogenous shocks in the model are correlated, and Dynare and Dynare++ do not treat this situation in the same way.
Dynare takes into account the correlation between the shocks: when it simulates an IRF for EPS, it simultaneously “adds” a shock on NU, because the two are correlated. Technically, Dynare identifies structural (independent) shocks underlying EPS and NU by performing a Cholesky decomposition of the variance-covariance matrix; the result of this process is dependent on the declaration order of the shocks. Only the first declared shock (EPS) is considered as structural, and NU is considered to be a linear combination of EPS and of an (unnamed) structural shock (which is thus independent from EPS). The IRFs with respect to NU actually corresponds to the response of the model to this unnamed structural shock.
On the other hand, Dynare++ ignores the correlation when computing the IRFs. It acts as if the shocks were independent, and thus adds no shock on NU when simulating an IRF for EPS.
I think the behaviour of Dynare is preferable, because it takes into account the declared correlation, and we can probably consider this to be a bug in Dynare++. But this is still a matter of interpretation. One could conversely consider that when one asks for the IRF of a shock, the implicit assumption is that this shock is independent from the others.
The best remains to avoid correlated shocks, and to only declare structural shocks.
Thank you for looking into that issue and for your informative response. You are right – when I remove the correlation between shocks, results from dynare and dynare++ are almost identical. Its also reassuring to know that different methods yield the same results – only small numerical discrepancies.
Thanks again for your help
Sorry for reviving an old topic. In the tutorial, it says “a fix point of the rule corresponding to a model with non-zero Σ” . Isn’t that most of the problems?
As I look into this more, aren’t most problems falling into the category of “stochastic fix point”?
If we have long-run risk and epstein-zin preference, shouldn’t we use dynare++ instead of dynare, as in Croce (2014)?
No. Dynare++ by default has a different representation of the same identical policy function. It’s not the case that the approximation point would be different so that the policy rules also would differ. Dynare actually uses the Dynare++ routines for higher order approximations. So there is no meaningful difference between the two anymore.
Actually Dynare++ has another feature, to which I guess @Noodle614 is referring, which is the approximation around the so-called stochastic steady state. This is currently not available in Dynare, though it should be added there soon. There are also theoretical challenges associated to this alternative approximation.
Hi, I am still trying to understand the subtle advantage dynare++ claims to have on “approximation around the so-called stochastic steady-state”. I was mostly thinking about the following
-
By doing higher-order stoch_simu, dynare can also calculate stochastic SS, right? Because the stochastic steady-state essentially refers to the impact of future volatility, which should be accounted for with order =3.
-
If I want to see the difference, is there a specific command I need to include in dynare++? Currently, I am examining the LRR model with dynare and dynare++, and they yield the same results–even for equity premium. So I am thinking about how to actually see the difference (significant ability on the approximation around the stochastic steady-state) you mentioned above?
Thank you!
The point is not about computing the stochastic steady state, but approximating the model around the stochastic steady state instead of the deterministic one. Put differently, Dynare only adjusts the constant at higher order, while Dynare++ also adjusts the slope of the decision rule.