An often heard request is a way to loglinearize a model instead of a linearization. Currently, the way to go is to put all variables in exp(). This is mechanic and error-prone work.
If it is easily doable, I would like to propose to use the preprocessor to make this substitution, similar to the predetermined_variables-command substituting the lag of the current period.
We could then add a command like
model(loglinearize)
to tell the preprocessor to loglinearize.
At the same time, we need a command like non_logarithmic_variables similar to the predetermined_variables command to exclude already logarithmic variables (like e.g. technology) or variables with a negative steady state. I think this is a better option than specifying explicitly which variables to substitute.
If possible, a design issue we would need to discuss is the behavior in steady state computation. I would suggest that the model(loglinearize) automatically triggers taking the log of the corresponding initvals so that users can enter the model in nonlinear standard form and Dynare takes care of the rest.
Edited
Designs
Child items ...
Show closed items
Linked items 0
Link issues together to show that they're related.
Learn more.
I do not think that it is necessary (nor efficient) to transform the model with the preprocessor by putting all the variables (or a subset of the variables) in exponential. This can be done by transforming the jacobian in the matlab code. This is precisely what we do with the loglinear option of the estimation command. This approach avoids the evaluation of the exponential functions (which has a cost) when calling the dynamic or static models.
I agree that it would be nice to have an interface for declaring that some variables should be linearized instead of being log-linearized. This is one of the main problem with the loglinear option of the estimation command (all the variables are then log-linearized).
I don't like the idea of having a syntax like model(loglinearize) because by this change of variable we do not intend to change the model but rather change the way we approximate and solve the model. So, I think that, as for the estimation command, the log-linearization should be instead an option of stoch_simul.
It would be really nice to have a general interface allowing us to declare any non linear transformations of the variables. They are some papers (by Judd and others) showing that the accuracy of the perturbation method is sensible to non linear transformation of the variables. Ideally these nonlinear transformation could be parameterizable (it would then be possible to optimize these parameters with respect to the accuracy of the solution).
There is a tradeoff between efficiency and implementation delay. Doing it more efficiently would be fine with me, but looks like a very long-term project. The problem currently is that log-linear only works for estimation and not stoch_simul and that it is only implemented at order 1.
A common issue is to do higher-order loglinear approximations in stoch_simul. Using the preprocessor seemed like the most straightforward way of getting the job done, particularly as the computational cost compared to estimation is rather small. If we opt for the transformation using the Jacobian, we need to do a lot of changes to many different part of the code, including k_order_pert, stochastic_solvers etc. At the same time, doing the manual exp() transformation that can be easily automatized already works now. Thus, I am not sure what is the best way to proceed.
I agree with your suggestion that the model option is not a good one and the a loglinear option of stoch_simulis preferable.
Having a general interface declaring non-linear transformations also seems like a good long-term feature. @stepan-a Are you thinking of implementing this via a Jacobian transformation?
My impression is that it is much more simple to do the transformation at the preprocessor level, because as @JohannesPfeifer mentioned, all the other parts of the code benefit automatically from it. While it is very tedious to implement Jacobian transformation at every relevant place in the MATLAB code. And if we do the transformation in the preprocessor, I do think that an option to model is the right place, because we really transform the model.
@stepan-a Why do you think that implementing the transformation at the preprocessor level is not efficient?
The implementation of log-linearization by manipulating the Jacobian matrix is trivial at first order... This is how we solve analytically the Solow/Ramsey models locally. I guess that it is no more difficult with higher order approximations, but I need to check (I remember that I've done that once on a growth model approximated at second order).
@sebastien-villemot The hard coded exponential transform of the variables does not transform the model, otherwise this transform would be wrong, but only the approximation of the model. Instead of writing the model for the level of the variables we write the model for the log of the variables, but it is exactly the same model from an economic view point (same preferences, technology, ...). The transformation at the preprocessor level is inefficient because we would have to evaluate a lot of exponential functions when evaluating the dynamic model. It is true that for the basic simulation usage this is not an issue. But for the estimation this may make a difference (also for the simulation of models with learning).
@JohannesPfeifer No, I think that it is not possible to implement arbitrary non linear transformation by manipulating the Jacobian.
Also, I think that these non linear transformations in the variables could help in solving perfect foresight models. This kind of tricks is used in econometrics since ages (for instance the Box-Cox transformation). On second thoughts this is an argument for doing the substitution with the preprocessor. I suspect that a perfect foresight model with growth would be easier to solve in logs (and in this case I don't think that it would be possible to do it by simply adapting the Jacobian matrix).
Willi Mutschlerchanged title from Use preprocessor for loglinearization to Use preprocessor for variable transformation
changed title from Use preprocessor for loglinearization to Use preprocessor for variable transformation
Willi Mutschlerchanged title from Use preprocessor for variable transformation to Use preprocessor for variable transformation (e.g. exp for doing approximation in log variables)
changed title from Use preprocessor for variable transformation to Use preprocessor for variable transformation (e.g. exp for doing approximation in log variables)
Willi Mutschlerchanged title from Use preprocessor for variable transformation (e.g. exp for doing approximation in log variables) to Use preprocessor for variable transformation (e.g. exp for doing approximation in log variables instead of level variables)
changed title from Use preprocessor for variable transformation (e.g. exp for doing approximation in log variables) to Use preprocessor for variable transformation (e.g. exp for doing approximation in log variables instead of level variables)
I don’t really understand why the issue is closed. It seems like everyone agreed that this would be a helpful feature having the variable substitution done by the preprocessor.
So assume you have the following simplified mod file:
var iv c y;model;y = c + iv;end;
Now for some reason I am interested in the log of y and c, but not of iv. Instead of appending auxiliary variables, I would manually transform my mod file to something like this:
var iv ln_c ln_y;model;exp(ln_y) = exp(ln_c) + iv;end;
so I did not change the model at all, just the definition of a variable. Here I also explicitly changed the variable names to reflect the change, but most often users dont do this but simply replace y by exp(y) and c by exp(c).
So I would like a feature where I would do the following
var iv;var(exp) c y;model;y = c + iv;end;
would then be transformed by the preprocessor to be equal to
var iv c y;model;exp(y) = exp(c) + iv;end;
so this is just a variable replacement of y with exp(y) and of c with exp(c). One could allow other transformations in the parentheses to var as well. I as a modeller have to keep that in mind, that y is now actually the inverse function of exp, i.e. equal to the log of y. I have seen this many times when people are using the SGU model framework and transform their variables using the symbolic toolbox of Matlab with f = subs(f, [x,y,xp,yp], exp([x,y,xp,yp]));
Evaluation of the Jacobian is of course more costly with exp(), but I don’t think that this is really a concern nowadays and more importantly it is a choice explicitly made by the user and not imposed by us by default.
So I would like to reopen this issue again and hope to find supporters for such a feature.
All transformations need to be handled internally, e.g. the user in all cases provides level variables for the steady state in initval, steady_state_model, or a _steadystate.m-file. Open question: how do we report output? The decision rules will depend on the log, suggesting that we also provide the steady state output for the logged variable, not the level.
Note that if the transformation is done at the preprocessor level, then the MATLAB routines would naturally work with and report the logged variables. Displaying the unlogged variables would require to introduce an additional level of complexity (i.e. some mechanism for the preprocessor to tell the MATLAB routines about the transformed variables, either via the introduction of auxiliary variables and equations, or by an ad hoc mechanism).
I would prefer that the transformation would be visible in all displayed messages for steady-state results, policy and transition functions, moments etc. So for instance, assume that I declared var(exp) y, but left all else, then I would like something like this:
I think this is easily done, if the preprocessor creates for example a boolean vector in M_ with the transformed variables. Then adapting our matlab displaying routines should be a bit of careful work, but nothing seriously difficult.