Hi.
> >>> >There is something loosely similar to what you need in the ODE
> >>> packages.
> >>> >This kind of algorithms also need some information to be provided
> >>> back to users during the algorithm run. For ODE solvers, it is at the
> >>> end of each integration step.
> >>> > [...]
> >>
> >> Does the this callback possibly influence the working of the algorithm?
> >
> > No, besides that you might decide to stop the algorithm based on the data.
> > This might also imply that you would like to restart it again...
>
> There may also be some information about behavior of the convergence, so
> I would say even if it does not change the state of the algorithm, it
> may be interesting for some users.
>
> >
> >> If so, it's not only information reported back to the user.
> >>
> >>> What I had in mind was quite similar, a callback interface and a
> >>> function very similar to addStepHandler() in the ODE case.
> >>> My "StepHandler" interface was rejected because it was specific to
> >>> CMA-ES.
> >>
> >> Not exactly; my concern is more that this kind of functionality is
> >> outside
> >> the realm of CM. IMO, CM should contain only mathematical/scientific
> >> algorithms.
>
> Yes, you are right.
>
> >> Other functionalities (such as logging/reporting) are general
> >> enough that tools already exist to provide them and these tools probably
> >> have already gone through the design pitfalls specific to this kind of
> >> tasks. If the functionality is really of importance, we should not do
> >> something quick and (potentially) dirty just because it would be
> >> sufficient
> >> to fit a single need, because once it is part of the library
> >> interface, it
> >> becomes fairly difficult to get rid of it when we discover the
> >> shortcomings
> >> of the design.
>
> You are also right on this, but I would not call this feature a
> "logging" feature. It's closer to reporting which is not the same and it
> may be interesting for algorithm users as it provides some mathematical
> information. I see it much more like StepHandler which is a clearly in
> commons-math scope than slf4j which is general purpose.
With something general, one can do anything.
But the logger which I had in mind might have a performance overhead that is
more important than checking whether some "handler" instance is null or not.
> Of course, you can use a general purpose framework for this sort of
> thing, but here I think we are more talking about monitoring a
> mathematical algorithm than monitoring a general purpose java program.
Yes. So what do you think of using something similar to the Java "Observer"
class?
interface HandlerSetter {
void setHandler(Handler handler);
}
interface Handler {
void update(HandlerSetter h, Object arg);
}
And an iterative algorithm that implements "HandlerSetter" will call
"update" after each iteration.
> [...]
>
> What about something along these lines (of course all names can be changed):
>
> public interface PointsSetsObserver {
>
> public enum Action {
> STOP,
> CONTINUE
> }
>
> public Action pointsSetChanged(List<double[]> pointsSet);
>
> }
>
> It could be used for all Nelder-Mead, Torczon's multidirectional and
> CMA-ES. It is probably not well suited for Levenberg-Marquardt or
> conjugate gradients.
I'm not sure I understand the proposed interface by it seems like a
mechanism meant to interfere with the algorithm (that will compete with
"ConvergenceChecker" for deciding whether to stop or continue).
Moreover it is still very specific. The above proposal is general (at the
cost that the "Handler" implementation must know the object typed passed to
the "update" method. But since the "setHandler" method is called by the
user, that should not be a problem.
> >>> Should we proceed with the review of the current implementation
> >>> without the event handling in place
> >>> or should we defer it until the event discussion Is finished?
> >>
> >> My choice is: "The algorithm first", together with unit tests.
> >> I hope that all agree that it's the most important. :-)
>
> Yes, we can start with a bare implementation and add the bells and
> whistles afterwards. In this case, they could also be integrated to the
> other optimization algorithms if something general enough is found.
+1
> [...]
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
