I usually see this message only when my gradient and objective functions
do not match each other. I debug by comparing a finite difference
approximation to the gradient with the result of the gradient function.
I think you can also run optim() without supplying a gr() function -
optim() will then use a finite difference approximation. If optim()
works fine like this with your function, that's a strong sign that your
gradient function doesn't match your objective function.
It is of course possible that your gradient function is properly
specified, and the function along the line being searched is so badly
behaved that the line search can't find a minimum in 20 steps. If
that's the case you might want to look in scaling issues, or
reformulating the problem.
It's also possible that even if you have a theoretically well-behaved
objective and gradient, your computation of may be subject to rounding
error and giving apparently discontinuous results to optim().
I'd look into all of the above possibilities before I tried increasing
the limit of 20 evaluations in the line search - in my experience 20
steps is plenty to find an adequate point for a reasonably well-behaved
function. It may be possible to increase the number of steps, but I
don't see how from the docs for ?optim. Of course, the source is available.
hope this helps,
Tony Plate
Petr Klasterecky wrote:> Hi,
> my call of optim() with the L-BFGS-B method ended with the following
> error message: ERROR: ABNORMAL_TERMINATION_IN_LNSRCH
>
> Further tracing shows:
> Line search cannot locate an adequate point after 20 function and
> gradient evaluations
> final value 0.086627
> stopped after 7 iterations
>
> Could someone pls tell me whether it is possible to increase the limit
> of 20 evaluations? Is it even worth doing so?
>
> My function(s) to be minimized are polynomial functions of tens of
> variables - let say 10 - 60 variables, all of them constrained to the
> (0,1) interval. Is it even possible and meaningfull to attempt such
> minimization? (Suppose I have good starting values.)
>
> Thaks, Petr