Unfortunately, the nebulous notion of this "trajectory" is exactly the
reason I desired a unified call to access it. And as a result, I
suppose I was essentially asking for a callback function for "whatever
this particular implementation of this particular algorithm decides it
means by 'iteration'", which obviously, wouldn't be wise to provide.
However, to make it more clear where my desire for a dichotomy between
"exploratory" and "trajectory" evaluations comes from, consider a
gradient-based algorithm that uses a simple approximation of the
gradient by probing the score at +/- epsilon around an anchor point
along each dimension. If I were designing such an algorithm, I would
consider the objective function evaluations involved in approximating
the gradient as "exploratory", and the evaluation made after determining
the steepest direction and taking a step as "along the trajectory."
Now, if I was visualizing the progression of the search, I would not
want to include all these noisy little +/- epsilon locations in my
trajectory, even if some of them happened to yield what was temporarily
a better result before the actual step was made to move the anchor point
downhill. But with no way of knowing which evaluations were made at
actual anchor points and which were for approximating the gradient, I
can't reliably produce that visualization.
For a non-gradient algorithm -- say, Nelder-Mead -- the "exploratory"
points would be those where a reflected point is calculated but found to
have a worse score and disregarded. In this case, simply keeping track
of the best solution so far does the trick, but the fact that this
technique will fail on algorithms like the gradient one described above
is what brought about my desire for a more unified way to handle this
reporting.
Still, you're absolutely right that a universally accepted definition of
"iteration" for the variety of algorithms supported in NLopt cannot be
formulated. When I posed my question originally, I was thinking of
simple cases like the examples I gave above, and not the wide variety of
algorithms supported in NLopt.
Greg
Steven G. Johnson wrote:
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
_______________________________________________
NLopt-discuss mailing list
[email protected]
http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/nlopt-discuss
