The REJECT option

[TomDoan]

Most RATS instructions which do non-linear optimization include a "REJECT" option. With this, you provide a function or formula that evaluates to "true" (non-zero) for any situation where you want the overall function to return an NA. This is done immediately (before any other calculations) and so can be helpful if you want to avoid doing a calculation that is nonsensical, or if you need to protect some part of your calculation that might be fail dramatically (that is, give an error) under some circumstances. This is an example from our code for Ireland(2004), "A Method for Taking Models to the Data", Journal of Economic Dynamics and Control, vol 28, no. 6, 1205-1226:

Code: Select all

dlm(startup=SolveModel(),y=yf,$
  a=afull,f=ffull,c=cfull,sw=swfull,presample=ergodic,$
  pmethod=simplex,piters=5,method=bfgs,iters=100,$
  reject=(eta<1.0.or.eta>1.05.or.rho>=1.0)) 1948:1 2002:2

eta is a (gross) growth rate. If it's less than 1.0, the whole solution process makes no sense. If it's too large (it's a quarter to quarter rate, so 1.05 is 20+% per year), there are numerical problems solving for the steady state of the DSGE. In the early iterations of a non-linear estimation, it's quite possible for rather extreme values to come up for evaluation. In most cases, you'll just get a really low likelihood (or a natural NA, if, for instance, they would require taking the log of a negative number), and they'll be rejected on that basis. REJECT can (and should) be used if something worse happens than a really low likelihood.

You can't use REJECT as a cheap way to impose a restriction when the boundary is feasible. If, for instance, your function is computable at x>=1.0 and you want to impose x<=1.0, you need to do a parameter set that includes

x x<=1.0

The option REJECT=(X>1.0) will cause the optimization to fail to converge if the function is increasing at x=1.0. Given the shape of the function, the optimization will naturally be testing values of x larger than 1. When it's told that the value there is NA (as a result of the REJECT), it will cut the step size, but will probably have to cut it quite a few times before getting down below 1.0. The next iteration will likely need even more subiterations in order to get under 1, etc. Eventually, it will hit a subiterations limit.

The proper course is to use the constrained optimization, which, in this case, will come in from above x=1.0. It uses a penalty function for values above 1.0, but that penalty function starts relatively small, so at least initially (given the shape of the function), it will have a higher total (likelihood less penalty) for values above 1. The penalty function increases as you iterate more, eventually dominating the function value and forcing x towards 1. You'll probably end up with the final estimated x being something like 1.000001.