Hello,
Le 22/11/2010 22:16, Gilles Sadowski a écrit :
> 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);
> }
It's quite convoluted and perhaps too general, but yes, I think
something along this line could be useful for long iterative algorithms.
I would probably prefer something more specialized, perhaps one or two
variants of this with HandlerSetter replaced by the existing algorithms
interfaces (i.e. one for optimization, another for root finding ...)
>
> And an iterative algorithm that implements "HandlerSetter" will call
> "update" after each iteration.
Yes, this is the way user can monitor what he wants. Perhaps with a few
set of more specialized handlers, the signature of the update method
could be adapted for the algorithm type (i.e a root solver would have a
search interval or an attempted value for example).
>
>> [...]
>>
>> 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).
I know, and it is not done this way for ODE in StepHandler (the
handleStep method is void). However, it is roughly done this way for
EventHandler where an eventOccurred method is precisely intended to
change the ODE solver behavior (it is an extension of the G-stop
mechanism). Since Nikolaus explained that one use case was to interrupt
the algorithm if it behaves badly in order to restart it with changed
settings, I have put this stop/continue return value. It could be
replaced by an exception in this case ...
> 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.
Yes, I think we have to find some compromise between too general (i.e.
one interface to rule them all) and too specific (one interface for each
algorithm implementation).
The key factor is how the user will use these features. I think when he
wants to monitor something, he already knows the global algorithm class
(root solving, optimization, ODE ...) and he easily agree to set up a
small implementation of an interface already dealing with the objects he
has lying around (the function, the solver, some boundary conditions
...). He will certainly not reuse an implementation he wrote for
monitoring a root solving when he wants to monitor an ODE, so having
different interfaces will probably not bother him. However, when dealing
with one specific problem (say ODE integration), he wants to be able to
change algorithm implementation (say from Dormand-Prince 8(5,3) to
Gragg-Bulirsch-Stoer), so having an interface which covers a complete
category of algorithms is important.
I guess there will not be a lot of such interfaces. With root solving,
optimization and ODE we are almost set. Perhaps we should go in deeper
details with optimization (direct methods, gradients methods ...).
To summarize, I think the Observer pattern is a good one, we already use
it for ODE, it should not be too general but should be tailored at type
of problem-solving level.
best regards
Luc
>
>
>>>>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
