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<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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
