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>
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>
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
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
We can make the statements mutually exclusive. But this does not solve the problem presented here of having two of the same statement in a mod file.
The warning does not solve the problem either. The problem, again, is that invoking any of these statements (either the same statement twice or two different statements) causes a problem because the first statement will declare a parameter (optimal_policy_discount_factor--M_.params(11) in this example--initialized either to 1 or the value passed to the planner_discount option). When the second statement is encountered, what will the warning say? That we are ignoring the initial value for the second statement or that we’re overwriting the initial value with the new one provided?
I see two solutions: 1) Only allow one of these statements in a .mod file. This would mean that the .mod file that started this discussion would be invalid because it contains two discretionary_policy statements. 2) Store the planner_discount and overwrite the initial value of the parameter before calling the matlab function associated with the statement.
Best, Houtan
On 31 Aug 2015, at 16:44, Johannes Pfeifer jpfeifer@gmx.de wrote:
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
Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev
1. Yes, Ramsey and discretionary_policy is a separate issue. I opened a ticket for it. 2. I would treat the planner_discount option like any other option (or parameter for that matter) and allow resetting it via the same statement later on. That would be option 2) I guess. If a warning is needed, I would provide a warning that the planner_discount has been updated. But again, I don't see the need for this warning. Changing parameters is common.
-----Ursprüngliche Nachricht----- Von: Dev [mailto:dev-bounces@dynare.org] Im Auftrag von Houtan Gesendet: Montag, 31. August 2015 17:04 An: List for Dynare developers Betreff: Re: [DynareDev] Preprocessor discretionary_policy
We can make the statements mutually exclusive. But this does not solve the problem presented here of having two of the same statement in a mod file.
The warning does not solve the problem either. The problem, again, is that invoking any of these statements (either the same statement twice or two different statements) causes a problem because the first statement will declare a parameter (optimal_policy_discount_factor--M_.params(11) in this example--initialized either to 1 or the value passed to the planner_discount option). When the second statement is encountered, what will the warning say? That we are ignoring the initial value for the second statement or that we’re overwriting the initial value with the new one provided?
I see two solutions: 1) Only allow one of these statements in a .mod file. This would mean that the .mod file that started this discussion would be invalid because it contains two discretionary_policy statements. 2) Store the planner_discount and overwrite the initial value of the parameter before calling the matlab function associated with the statement.
Best, Houtan
On 31 Aug 2015, at 16:44, Johannes Pfeifer jpfeifer@gmx.de wrote:
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
Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev
_______________________________________________ Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev
-
Houtan -
Johannes Pfeifer -
Michel Juillard