Matthieu

(regarding the final question, but not the ones before that.)

The short answer is that you seem to have a solution, since hessian in numDeriv works. The long answer follows.

Outside a constraint area one cannot assume that a function will evaluate properly. Some constraints are imposed because the function is not defined outside the region. This would mean that the gradient and hessian are not defined in the usual sense at the boundary; the "left" and "right" derivatives should exist and be the same in the limit. I have had on my to-do list for some time a project to add one-sided approximates in numDeriv, but that will probably not happen soon. If your solution is actually on the boundary, you might consider some substitution which removes the constraint, and consider the hessian on the reduced, unconstrained, space.

In your situation I would also be concerned about the optimum being very close, but not on the boundary. You might want to check that this is not an artifact of the convergence criteria. Check that the objective is actually inferior at a point on the boundary close to your optimum. Also, the gradient should be zero at the optimum, but that may not be exactly so because of numerical convergence criteria. If the gradient is pointing toward the boundary, that is a sign that you may just have converged too soon.

Also, the hessian coming from the optimization is built up as an approximation using information from the steps of the optimization. I am not familiar enough with the numerical handling of boundary constraints to know how this approximation from the optimization might be affected, but you may need to be careful in this regard.

Paul

On 12-11-15 10:25 AM, Matthieu Stigler wrote:
Hi

I am trying to recover the hessian of a problem optimised with
box-constraints. The problem is that in some cases, my estimates are
very close to the boundary, which will make optim(..., hessian=TRUE) or
optimHessian() fail, as they do not follow the box-constraints, and
hence estimate the function in the unfeasible parameter space.

As a simple example (my problem is more complex though, simple param
transformations do not apply ashere), imagine estimating mu and sigma
(restricted to be >0) of a simple normally distributed data, where
however the true sigma is very close to zero:

LLNorm <- function(para, dat=rn)  return(-sum(dnorm(dat, para[1],
para[2], log=TRUE)))
rn2 <- c(rep(10.3, 2000), 10.31)

 >optim(c(10,1), fn=LLNorm, method="L-BFGS-B", lower=c(-Inf, 0.0000001),
dat=rn2,hessian=TRUE)
Error in optim(c(10, 1), fn = LLNorm, method = "L-BFGS-B", lower =
c(-Inf,  : non-finite finite-difference value [2]

The only solution/workaround I found is to do a two steps procedure: use
optim() without hessian, then use optimHess, specifying the length of
the numerical variations (arg ndeps) as smaller as the distance between
the parameter and the bound, i.e.:
op<-optim(c(10,1), fn=LLNorm, method="L-BFGS-B", lower=c(-Inf,
0.0000001), dat=rn2,hessian=FALSE)

H<-optimHess(op$par, LLNorm, dat=rn2,
control=list(ndeps=rep((op$par[2]-0)/1000,2)))

While this solution "works", it is surely not elegant, and I have
following questions:
1) is this solution to use smaller steps good at all?
2) I am not sure either I understand the reasons why the hessian in a
constrained optim problem is evaluated without the constraints, or at
least the problem transformed into a warning?

Furthermore, I realised that using the numDeriv package, the function
hessian() does not offer either constraints for the parameters, yet in
the special case of the example above, it does not fail (although would
have problems with parameter even closer to the bound), unlike the
optimHessian() function? See:
library(numDeriv)
hessian(LLNorm, op$par, dat=rn2)

This brings me to the final question: is there a technical reason not to
allow a "constrained" hessian, which seems to indicate the fact that the
two implementations in R do not do it? I found a very interesting answer
by Spencer Grave for  a similar question:
http://tolstoy.newcastle.edu.au/R/e4/help/08/06/15061.html
although this regards more the statistical implications than the
numerical issues.

Thanks a lot!

Matthieu

______________________________________________
R-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Reply via email to