I agree that it needs to be in M_.params. I dislike parameters being in the workspace as there is nothing that guarantees their value coincides with the one stored in M_, but this is a different issue. For consistency, it should be there.
Why do we even need a warning? We don't print warnings when users change other parameters.
Regarding different optimal policies in the same mod-file: can't we just use the preprocessor to make ramsey and discretionary_policy mutually exclusive?
-----Ursprüngliche Nachricht----- Von: Dev [mailto:dev-bounces@dynare.org] Im Auftrag von Michel Juillard Gesendet: Montag, 31. August 2015 16:30 An: List for Dynare developers Betreff: Re: [DynareDev] Preprocessor discretionary_policy
We need optimal_policy_discount_factor to be in M_.params because it is the way to pass it to *_dynamic() and *_static()
From the start of Dynare, parameters exist with their name in the workspace. Some people rely on this to quickly check a value.
So, it would be an exception to the general rule that the optimal_policy_discount_factor isn't in the workspace
I think that the error on optimal_policy_discount_factor already existing should be replaced by a warning as it is unlikely that somebody usea the parameter name "optimal_policy_discount_factor" for a different purpose.
It remains that I don't believe that Ramsey and discretion can co-exist in the same *.mod file
Best
Michel
Johannes Pfeifer writes:
Hi,
I don’t see the point of this. The preprocessor sets
M_.params( 11 ) = M_.params(2);
optimal_policy_discount_factor = M_.params( 11 );
But then the variable optimal_policy_discount_factor in the workspace is never used again. Rather, we always use get_optimal_policy_discount_factor.m to retrieve the value directly from M_.params. Can’t we just drop assigning this variable?
Best,
Johannes
Von: Dev [mailto:dev-bounces@dynare.org] Im Auftrag von Houtan Gesendet: Montag, 31. August 2015 15:16 An: List for Dynare developers Betreff: Re: [DynareDev] Preprocessor discretionary_policy
The problem is precisely because there are two discretionary_policy statements. The preprocessor creates a parameter called optimal_policy_discount_factor from the planner_discount option or, if it doesn’t exist, declares it and sets it equal to 1. As parameter and variable names are unique, when the preprocessor encounters the second discretionary_policy statement with the planner_discount option, it breaks because it tries to declare a parameter with a name that is already taken. If you remove this second option, you will see that it will run all the way through, using the discount_factor declared in the first statement.
If we do indeed want to support multiple discretionary_policy, ramsey_model, and ramsey_policy statements in a .mod file, we will need to think of a slight hack (perhaps storing the value of planner-discount in the statement options and overwriting the optimal_policy_discount_factor parameter with this value when before calling discretionary_policy and the like (ramsey_model, ramsey_policy).
Best,
Houtan
On 30 Aug 2015, at 11:44, Johannes Pfeifer pfeifer@uni-mannheim.de wrote:
Hi Houtan, could you please look at the attached mod-file. It triggers the error message:
ERROR: Gali_discretion.mod: line 145, cols 45-66: Symbol optimal_policy_discount_factor is needed by Dynare when using a ramsey_model, a ramsey_policy or a discretionary_policy statement
I don’t know where it comes from. There is no symbol “optimal_policy_discount_factor” and planner_discount has been specified (the first call to discretionary_policy even works)
Johannes Pfeifer
Department of Economics
University of Mannheim
L7, 3-5, Room 242
68131 Mannheim
Germany
+49 (0)621 181-3430
<Gali_discretion.mod>
Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev
-- Michel Juillard _______________________________________________ Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev