Hi Marco,
Thanks for the quick reply. That is fine with me. The compatibility was nowhere documented and judging from the code you had already done precautions for these other algorithms. The reason I send you the unit test is that for some algorithms it break down with seemingly easily fixable problem like unconformable matrices where a transpose seem to be missing. But if they are not implemented at all, we should probably just document this and filter out these cases. If I understand you correctly, only kalman_algo=1 is supported. I would then add a check for this.
For now I would appreciate if you could have a look at the newrat-implementation in https://github.com/DynareTeam/dynare/pull/817. We could then work from there.
Best,
Johannes
--
Johannes Pfeifer
Friesenwall 104
50672 Köln
Tel.: +49-221-29873852
Mobil.: +49-170-6936820
Germany
Von: Dev [mailto:dev-bounces@dynare.org] Im Auftrag von Marco Ratto
Gesendet: Freitag, 5. Dezember 2014 08:32
An: List for Dynare developers
Betreff: Re: [DynareDev] newrat
Hi Johannes,
I have to think about this. Not sure how much quickly, however. Analytic derivation should only work with multivariate stationary filter. All other filters should be broken (no analytic derivs in all other filters).
best
Marco
On 12/4/2014 6:20 PM, Johannes Pfeifer wrote:
Hi Marco,
I am trying to factorize the mode-finding code to make it reusable in other parts of Dynare. But I am having a hard time with newrat in master. The reason is that newrat is the only optimizer that endogenously changes other options used inside of the objective function. I would really like to get rid of this behavior as it makes the generic passing of input arguments to objective functions impossible. One always needs to make sure that the updated options is passed.
To be specific, the problem in master derives from the fact that the analytic Hessian requires options_.kalman_algo to be either 2 or 4. If this is not the case, newrat sets one of these values. My proposal to remedy this would be to only allow using newrat without options_.analytic_derivation when kalman_algo=2 or kalman_algo=4. That is, when not using analytical derivatives the user must at least specify a Kalman algo that allows for analytical derivatives. Such a check would make changing the options redundant. Or do you envision cases where people want an analytical Hessian based univariate filters while wanting to compute the likelihood in mode-finding based numerical derivatives derived from the multivariate Kalman filter.
An additional issue that popped up: currently, newrat with analytical_derivation seems to be broken for most Kalman algorithms. Thus, I cannot test the features/changes I propose. I created a pull request with a unit test for these issues. I attach the files you need to trace out the errors.
Best,
Johannes_______________________________________________Dev mailing listDev@dynare.orghttps://www.dynare.org/cgi-bin/mailman/listinfo/dev
--
Marco Ratto,
Financial and Economic Analysis
Joint Research Centre
The European Commission,
marco.ratto@jrc.ec.europa.eu