Dear George,
optimziation routines such as csminwel (or fmincon) need only a rough Hessian, and use brute force to keep it definite positive.
It is not appropriate to compute the standard error of the posterior mode, that is why we recompute it using a 7-point formula, but, of course, you need to really be at the correct mode to obtain a positive definite hessian.
I imagine that in some cases the hessian returned by the optimization routine can do as variance matrix for the proposal, but in other cases, it can't. In doubt, we force the user the refine his/her mode before going into Metropolis.
Best,
Michel
G. Perendia wrote:
Dear Michel
Working on Part Info integration we are experiencing frequent problem with models that run only to end of the first, the ML /mode stage and fail to run MCMC because they fail to calculate chol(vv), this due to the hessian of the estimated parameters not being positive definite - this problem is hampering PI tests:
??? Error using ==> chol Matrix must be positive definite. Error in ==> metropolis_hastings_initialization at 52 d = chol(vv);
Why is Dynare using the additional parameter hessian calculation (i.e using hessian()) in dynare_estimation_1.m when the last one (already inverted) returned from csminwel (the default gradient optimiser, or from fmincon) and passes chol(), may be used for MCMC stage instead (i.e. as is the situation for the optimiser cases 5 - newrat & 6)?
What is disadvantage of using hessian_csminwel instead? (I do understand though that some of the other optimisers do not produce the Hessian and such calculation is then needed)
Best regards
George artilogica@btconnect.com mailto:artilogica@btconnect.com