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?

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

Reply via email to