Hi Michel,
I does not look like the updating of lead_lag_incidence has to do with Ramsey being run earlier. The Gali_discretion.mod does not run without this. It will otherwise crash in the displaying of autocovariances. This happens even if I comment out all code related to the resetting of information in M_
Best,
Johannes
-----Ursprüngliche Nachricht----- Von: Michel Juillard [mailto:michel.juillard@mjui.fr] Gesendet: Sonntag, 30. August 2015 17:01 An: Johannes Pfeifer Cc: stepan@dynare.org Betreff: Re: AW: AW: AW: AW: AW: Trouble with planner objective
Johannes Pfeifer writes:
Ok. Thanks. I just pushed several commits to https://github.com/DynareTeam/dynare/pull/1042 that are related to this. The unit test confirms that everything works fine when computing the planner objective with discretionary policy, even when initval is specified for the first period.
The issue I still don't understand is why discretionary_policy affects lead_lag_incidence (https://github.com/JohannesPfeifer/dynare/commit/3b64c37cb30ec2e3171205dad34...). I find this very prone to errors.
I think it is only to recover the original lead-lag structure in case Ramsey policy as been ran in the same *.mod file. It is a left-over of the previous implementation of Ramsey policy. Now, I believe that it would great bigger problems. I don't know if we filter these cases.
Best
Michel
Send me the example please
Best
Michel
Johannes Pfeifer writes:
Hi Michel,
I does not look like the updating of lead_lag_incidence has to do with Ramsey being run earlier. The Gali_discretion.mod does not run without this. It will otherwise crash in the displaying of autocovariances. This happens even if I comment out all code related to the resetting of information in M_
Best,
Johannes
-----Ursprüngliche Nachricht----- Von: Michel Juillard [mailto:michel.juillard@mjui.fr] Gesendet: Sonntag, 30. August 2015 17:01 An: Johannes Pfeifer Cc: stepan@dynare.org Betreff: Re: AW: AW: AW: AW: AW: Trouble with planner objective
Johannes Pfeifer writes:
Ok. Thanks. I just pushed several commits to https://github.com/DynareTeam/dynare/pull/1042 that are related to this. The unit test confirms that everything works fine when computing the planner objective with discretionary policy, even when initval is specified for the first period.
The issue I still don't understand is why discretionary_policy affects lead_lag_incidence (https://github.com/JohannesPfeifer/dynare/commit/3b64c37cb30ec2e3171205dad34...). I find this very prone to errors.
I think it is only to recover the original lead-lag structure in case Ramsey policy as been ran in the same *.mod file. It is a left-over of the previous implementation of Ramsey policy. Now, I believe that it would great bigger problems. I don't know if we filter these cases.
Best
Michel
Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev
It's at https://github.com/JohannesPfeifer/dynare/commit/752bc543b4a312ee64c97487cea... Just delete the last planner_discount statement as this will trigger the preprocessor error discussed today. That mod-file is the reason why I made the bugfix https://github.com/JohannesPfeifer/dynare/commit/3b64c37cb30ec2e3171205dad34...
-----Ursprüngliche Nachricht----- Von: Dev [mailto:dev-bounces@dynare.org] Im Auftrag von Michel Juillard Gesendet: Montag, 31. August 2015 20:04 An: List for Dynare developers Betreff: Re: [DynareDev] lead_lag_incidence in discretionary_policy
Send me the example please
Best
Michel
Johannes Pfeifer writes:
Hi Michel,
I does not look like the updating of lead_lag_incidence has to do with Ramsey being run earlier. The Gali_discretion.mod does not run without this. It will otherwise crash in the displaying of autocovariances. This happens even if I comment out all code related to the resetting of information in M_
Best,
Johannes
-----Ursprüngliche Nachricht----- Von: Michel Juillard [mailto:michel.juillard@mjui.fr] Gesendet: Sonntag, 30. August 2015 17:01 An: Johannes Pfeifer Cc: stepan@dynare.org Betreff: Re: AW: AW: AW: AW: AW: Trouble with planner objective
Johannes Pfeifer writes:
Ok. Thanks. I just pushed several commits to https://github.com/DynareTeam/dynare/pull/1042 that are related to this. The unit test confirms that everything works fine when computing the planner objective with discretionary policy, even when initval is specified for the first period.
The issue I still don't understand is why discretionary_policy affects lead_lag_incidence (https://github.com/JohannesPfeifer/dynare/commit/3b64c37cb30ec2e3171205dad34...). I find this very prone to errors.
I think it is only to recover the original lead-lag structure in case Ramsey policy as been ran in the same *.mod file. It is a left-over of the previous implementation of Ramsey policy. Now, I believe that it would great bigger problems. I don't know if we filter these cases.
Best
Michel
Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev