On Aug 16, 2010, at 6:25 PM, Greg Nicholas wrote:
In most cases, putting the reporting code in the objective function
and only calling it when the new solution is better will do the
practical job of keeping track of the trajectory of the search.
However, there are a couple of cases off the top of my head that
this won't be exact for, neither of them involving nonlinear
constraints.
1. Global optimization algorithms that don't guarantee monotonic
convergence to the minimum will not have each iteration tracked if
only best solutions are recorded. If all solutions are recorded,
then any "exploratory" calls to the objective function will end up
becoming part of the trajectory.
2. Consider a simple coordinate descent algorithm that takes a step
to its left, computes the gradient at this point (which also happens
to be the best solution so far, and is therefore recorded), then
takes a step to its right and throws an exception. The log of the
trajectory will suggest the search ended at the left-step point,
whereas the current solution never actually did reach that point.
And yes, I'm very aware that these cases are splitting hairs
(especially #2) and in practice, if a solution was tried for any
reason and determined to be feasible and minimal is all that
matters. But darn it, the obsessive compulsive part of me wants a a
nice, pure log file, free of clutter from extraneous states that
were never officially a current state in my search!
My motivation comes from an application I'm building that uses NLopt
algorithms interchangeably along with other already existing
homegrown optimizers. The homegrown ones are built to print out
status at every full state along the search path, so if I attempt to
mirror this behavior for the NLopt algorithms, I'll end up either
printing inter-iteration states or skipping reports for transitions
to worse states. Both of these aren't terribly appealing. Of course,
in no way is this essential functionality, but I wanted to inquire
about it anyway.
I'm still confused about what exactly you want. In case #1, why are
"exploratory" calls not part of "the trajectory"? In case #2, what do
you mean by "never actually did reach that point" ... it evaluated
that point, so in what sense did it not "reach" it? (Note that even
if you throw an exception in the middle of an "iteration", equivalent
to a force_stop call, NLopt generally returns the best feasible point
found so far even if it was not found at the end of an "iteration".)
Can you give me a well-defined, unambiguous definition of the
"trajectory" you want that is neither (a) every evaluated point,in
order of evaluation nor (b) every evaluated point that in some sense
improves the objective (either by being a feasible point with a better
objective, or by improving feasibility)?
I would hate to add a callback function whose definition was only
"whatever this particular implementation of this particular algorithm
decides it means by an `iteration' ," especially with no guarantee
that what I think is an `iteration` coincides with what you think is
an `iteration`. (And what would it do for global-search algorithms
that are exploring multiple regions per "iteration"?)
Steven
_______________________________________________
NLopt-discuss mailing list
[email protected]
http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/nlopt-discuss
