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.
Phil
>
> Best regards,
> Sebastien
>
> 2011/8/10 Greg Sterijevski <gsterijev...@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-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
