NKM.mode in tests/occbin on github

Occbin
1

I have some quick questions regarding the script: dynare/testser/occbin/filter/NKM.mod.
(1) Why the constraint is on inom instead of inmnot? In one case I found that using inom constraint gives the result that inmnot>1 and inom=1.
(2) Why the covariance is set to 0 when inom is None?

Thank you for your help in advance!

2
  1. I don’t know the answer. @rattoma should know. I agree that this looks strange.
  2. The reason is that the monetary policy shock needs to drop out of the model when the ZLB binds.
3

Thank you very much for your prompt responses!

During my experimental runs with OccBin, I encountered two additional issues, and I would greatly appreciate any assistance you could provide.

  1. In the function occbin_kalman_update0 within the script matlab/+occbin/kalman_update_algo_1.m, line 374 suggests that the rank of F might be smaller than its size due to some OBC regime triggering singularity. I have observed instances where singularity also occurs in line 99, within the function kalman_update_algo_1 of the same script. Should we consider implementing similar treatments for F in this case?
  2. In the script matlab/+occbin/kalman_update_engine.m, line 423 indicates that if there are multiple solutions, the final likelihood is the sum of the computed likelihoods. I am puzzled as to why we would want to sum all of them. Additionally, if starting from both the base regime and the previously guessed regime yields no valid solutions, but the brute force approach manages to find one, we end up with likvec= [inf, float] and the returned likx being likx=inf. This results in an invalid overall likelihood despite having found a solution through brute force. Would it not be more appropriate to set likx as the minimum element of likvec?

Thank you once again!

I can provide more details, including the parameter values used and the model mod file. Please note that the line numbers refer to the files available on GitHub.

4

This is a question that should probably be addressed to @rattoma

5

@jodie0399 Sorry for the delay. Thanks for pointing this out. The first issue was addressed in kalman_update_algo_1.m: filter out singular forecast error variance (65ff5f0f) · Commits · Dynare / dynare · GitLab.
The second issue will be addressed with First set of commits preparing OccBin for later particle filter implementation (!2436) · Merge requests · Dynare / dynare · GitLab. The reason for the sum is that you have two potential solutions. Hence, the likelihood of the parameter draw is the sum of the likelihood of the two solutions.