commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <Luc.Maison...@free.fr>
Subject Re: [math] Monitoring iterative algorithms
Date Thu, 11 Aug 2011 09:27:09 GMT
Le 11/08/2011 06:14, Phil Steitz a écrit :
> On 8/10/11 8:19 PM, Sébastien Brisard wrote:
>> Hello,
>> going back to the initial conversation. It seems to me that
>> formalizing Iterative Algorithms in a general way is very interesting,
>> but not a realistic target for 3.0 (or probably even 3.1). However, I
>> would very much like to have a satisfactory working version of linear
>> iterative solvers. I've already implemented them at work, because I
>> really need them. Including them in Commons Math seems to me highly
>> desirable, but if that too is unrealistic, let me know. As I'm doing
>> this last part in my spare time, I would become available to work on
>> other, more urgent open issues.
>> So here is what I propose. For the time being, iterative linear
>> solvers can live without observers, since I can reverse a previous
>> argument: convergence checkers can be seen as monitors... so I can
>> (dirtily) tweak a checker to monitor my solver (this would be a
>> temporary solution, waiting for something better). Regarding
>> convergence checkers themselves (the other major issue raised in the
>> code I have already proposed), I think the Object model is easier to
>> derive, and something like
>> StoppingCriterion<STATE>{
>>    init(LinearIterativeSolver solver);
>>
>>    boolean hasConverged(STATE s);
>> }
>> should work (will polish it a little bit). Making the stopping
>> criterion generic would allow later use in e.g. GA (STATE=Population)
>> and Optimization.
>>
>> On second (third? fourth?) thoughts, I've realized that
>> Obervable/Observer would probably not be flexible enough, even for
>> very simple observers. A real event listener should probably be
>> preferred. For example, in many iterative solvers, there is an
>> initialization phase, during which the loop has not started, but the
>> counter (function evaluations, matrix-vector products) has. So a
>> different event should probably be fired, depending on whether or not
>> we are in the main loop.
>>
>> OK, so, to sum up: I get rid of any Observer/Listener in the existing
>> code (this will come up later, once Iterative Algorithms at large have
>> been discussed). I write a generic enough stopping criterion
>> interface. This could be done rather quickly. Question is: would it be
>> agreeable to the Commons Math community?
>
> Sounds reasonable to me; though I would personally be fine with
> adding some small classes along the lines of what I outlined above
> to support events.  They could even be package-scoped if we want to
> keep them out of the public API and replace later with more general
> constructs used elsewhere in [math].  We are not talking about much
> code at all here.
>
> I think if you are careful, you can likely set this up so that you
> can continue to add features to the event framework (or even add the
> framework itself) and stopping criteria without breaking backward
> compatibility in 3.x releases.
>
> I would like to see this in 3.0 if you can get something simple
> completed that can be enhanced incrementally in 3.x and possibly
> refactored in 4.0.

This seems a good path to go.

Luc

>
> Phil
>>
>> Best regards,
>> Sebastien
>>
>> 2011/8/10 Greg Sterijevski<gsterijevski@gmail.com>:
>>> Luc,
>>>
>>> I think we misunderstood each other, in the snippet below, my intention was
>>> to agree with him. Everything Gilles was agreeable and hard to argue
>>> against.
>>>
>>> -Greg
>>>
>>>> Luc
>>>>
>>>>
>>>>   Not sure what you mean.
>>>>>
>>>>>   In my opinion, discussions should serve to solve real problems of a
>>>>>> software
>>>>>> library: bugs, design inconsistencies, efficiency improvements (in
that
>>>>>> order).
>>>>>>
>>>>>>
>>>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message