FORCED_STOP from OptimizationNLopt callback returns best point PRIOR to callback, making it unuseful for custom stopping criteria. Is that intended? #767
Labels
question
Further information is requested
Question❓
An OptimizationNLopt solve that results in FORCED_STOP from a callback will return not the point that generated the stop, but the previous best point. Perhaps this is intended, but it means defining stopping criteria in the callback will not be useful. (For related background see this issue).
For example, suppose the callback function defines complex stopping criteria, and those criteria are met on iteration 4, at which point the callback function returns true. Suppose the objective function values on iterations 1 through 4 are 1000, 10, 100, and 1. The callback will return the sol.u values from iteration 2, when the objective value was 10, not the sol.u values from iteration 4 when the objective value was 1.
This means we do not recover the point at which the complex stopping criteria were met - a point we likely want.
The test code lines 75-84, copied below, seems to recognize this and suggest that this behavior results from NLopt rather than Optimization.NLopt -- see the comment "#nlopt gives the last best not the one where callback stops" on line 82, copied below. (Incidentally, the test does not appear to call the callback.)
Is this desirable, and if not, is there a way to work around it? At least in my case, it is not desired - I'd like to be able to get the point that generated the FORCED_STOP, because it met my stoppping criteria.
Many thanks.
The text was updated successfully, but these errors were encountered: