# Restricting parameters in Dynare

**URL:** <https://forum.dynare.org/t/restricting-parameters-in-dynare/4701>\
**Category:** Dynare help (legacy posts)\
**Created:** [19 May 2015 14:15 UTC](https://forum.dynare.org/t/restricting-parameters-in-dynare/4701 "2015-05-19T14:15:35Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![German](https://forum.dynare.org/letter_avatar_proxy/v4/letter/g/c67d28/32.png) [@German](https://forum.dynare.org/u/German)\
**Post date:** [19 May 2015 14:15 UTC](https://forum.dynare.org/t/restricting-parameters-in-dynare/4701/1 "2015-05-19T14:15:35Z")

</div>

Hello,

I am trying to optimize the parameters of a simple Taylor rule in a neo-keynisian enviroment.

The parameters turn out to be non-sensical. I was wondering if you could give me some insight:

1. Is there a possibility to impose a restriction to the parameters.
2. If not, what do you recommend?

Thank you,  
Germán

---

<div class="post-metadata">

**Author:** ![jpfeifer](https://forum.dynare.org/user_avatar/forum.dynare.org/jpfeifer/32/5044_2.png) [@jpfeifer](https://forum.dynare.org/u/jpfeifer)\
**Post date:** [19 May 2015 17:27 UTC](https://forum.dynare.org/t/restricting-parameters-in-dynare/4701/2 "2015-05-19T17:27:03Z")

</div>

Which context are we talking about? In OSR, this is not easily possible yet.  
In estimation, you can use the estimated\_params-block to set upper and lower bound for your parameters or specify a prior that does not allow the parameters to be bigger than certain bounds.

---

<div class="post-metadata">

**Author:** ![German](https://forum.dynare.org/letter_avatar_proxy/v4/letter/g/c67d28/32.png) [@German](https://forum.dynare.org/u/German)\
**Post date:** [19 May 2015 20:24 UTC](https://forum.dynare.org/t/restricting-parameters-in-dynare/4701/3 "2015-05-19T20:24:03Z")

</div>

Thank you for your reply.

Actually, I was thinking of implementing it on an OSR…could you help me providing some guidance in order to do this?

Thank you again.

Kind Regards,  
Germán

---

<div class="post-metadata">

**Author:** ![jpfeifer](https://forum.dynare.org/user_avatar/forum.dynare.org/jpfeifer/32/5044_2.png) [@jpfeifer](https://forum.dynare.org/u/jpfeifer)\
**Post date:** [23 May 2015 11:13 UTC](https://forum.dynare.org/t/restricting-parameters-in-dynare/4701/4 "2015-05-23T11:13:37Z")

</div>

This is somewhat complicated. Please provide your current codes and indicate the bounds you want to set and I will try post an example.

---

<div class="post-metadata">

**Author:** ![German](https://forum.dynare.org/letter_avatar_proxy/v4/letter/g/c67d28/32.png) [@German](https://forum.dynare.org/u/German)\
**Post date:** [26 May 2015 15:53 UTC](https://forum.dynare.org/t/restricting-parameters-in-dynare/4701/5 "2015-05-26T15:53:40Z")

</div>

Thank you again for your reply.

This is my mod file.

Kind Regards,  
Germán  
[sinramsey.mod](https://forum.dynare.org/uploads/default/original/2X/d/d7c5857ff15869cfbff17746b3b5163d302175c5.mod) (4.21 KB)

---

<div class="post-metadata">

**Author:** ![jpfeifer](https://forum.dynare.org/user_avatar/forum.dynare.org/jpfeifer/32/5044_2.png) [@jpfeifer](https://forum.dynare.org/u/jpfeifer)\
**Post date:** [27 May 2015 17:08 UTC](https://forum.dynare.org/t/restricting-parameters-in-dynare/4701/6 "2015-05-27T17:08:11Z")

</div>

Dear Germán,

you need to use the current unstable version (to be Dynare 4.5) with the attached files. In osr\_optimizer\_function\_wrapper.m you can manually change the bounds (and the optimizer to use). It currently requires a Matlab Toolbox as I am using fmincon as an example. Note also that there is a bug in the current unstable that will soon be fixed. You need to replace in dynare\_minimize\_objective.m the calls to

> [@](#):
>
> options\_.mode\_compute

by

> [@](#):
>
> minimizer\_algorithm

See [github.com/JohannesPfeifer/dynare/commit/be58d739d4b2338977395bceee6780955915310c](https://github.com/JohannesPfeifer/dynare/commit/be58d739d4b2338977395bceee6780955915310c)  
[sinramsey.mod](https://forum.dynare.org/uploads/default/original/2X/8/8053c4072d599e03dc5014bab6ef2a2231f5bf70.mod) (4.25 KB)  
[osr\_optimizer\_function\_wrapper.m](https://forum.dynare.org/uploads/default/original/2X/3/37c83cd260eb6c965203867508eedd56759aa54c.m) (689 Bytes)

---

<div class="post-metadata">

**Author:** ![fabiac](https://forum.dynare.org/user_avatar/forum.dynare.org/fabiac/32/5566_2.png) [@fabiac](https://forum.dynare.org/u/fabiac)\
**Post date:** [14 July 2015 13:19 UTC](https://forum.dynare.org/t/restricting-parameters-in-dynare/4701/7 "2015-07-14T13:19:41Z")

</div>

Dear Dr. Pfeifer,

does this solution already apply to the current stable version of Dynare? Thanks

---

<div class="post-metadata">

**Author:** ![jpfeifer](https://forum.dynare.org/user_avatar/forum.dynare.org/jpfeifer/32/5044_2.png) [@jpfeifer](https://forum.dynare.org/u/jpfeifer)\
**Post date:** [15 July 2015 06:48 UTC](https://forum.dynare.org/t/restricting-parameters-in-dynare/4701/8 "2015-07-15T06:48:57Z")

</div>

No, it only works with the unstable, to be published as Dynare 4.5

---

<div class="post-metadata">

**Author:** ![Vermandel](https://forum.dynare.org/user_avatar/forum.dynare.org/vermandel/32/5866_2.png) [@Vermandel](https://forum.dynare.org/u/Vermandel)\
**Post date:** [21 July 2015 13:52 UTC](https://forum.dynare.org/t/restricting-parameters-in-dynare/4701/9 "2015-07-21T13:52:27Z")

</div>

Hello Johannes,

After reading your code, I’m wondering whether osr now works with second order approximation to the model’s policy function? (I’m asking because of the “order=2” in the osr command).

Best,  
gauthier

---

<div class="post-metadata">

**Author:** ![jpfeifer](https://forum.dynare.org/user_avatar/forum.dynare.org/jpfeifer/32/5044_2.png) [@jpfeifer](https://forum.dynare.org/u/jpfeifer)\
**Post date:** [22 July 2015 08:13 UTC](https://forum.dynare.org/t/restricting-parameters-in-dynare/4701/10 "2015-07-22T08:13:00Z")

</div>

No, because a first order approximation already delivers second-order accuracy in the unconditional moments, which osr minimizes. Going to second order would yield fourth-order accuracy.
