Hello all, @Greg: I've modified the constructor according to your message on JIRA this.listeners = new CopyOnWriteArrayList<IterationListener>(); Is that what you were concerned about? I'm sorry to say I know nothing on thread issues, and I could use your help! I'm almost certain I will be facing a potential thread-safety issue with ArrayRealVector.UnmodifiableRealVector in IterativeLinearSolvers, but I will submit a practical case to discuss about once I've committed the conjugate gradient code, I think it will make your life easier.
@all: I think we are all more or less happy with the event handling, but we are all not really happy with the way custom stopping criteria are implemented. Maybe this last point requires more thought. Since I've reverted to Gilles proposition that every iterative algorithm should have a default stopping criterion, I propose to remove completely the (somewhat not so clean) 'shouldStop' method from the IterationManager. This or other approaches can be added at a later point. This way, we would be able to test the monitoring framework in practical applications (the code for CG is ready, SYMMLQ will follow), and see where the main weaknesses lie. Do you agree with that? If yes, I'll modify all event-handling related methods along the lines indicated above, and set the stopping criterion issue aside for the time being. It's true this discussion requires applications on which we could base our arguments. Regarding the point on what exception should be thrown. I agree with Gilles that it should be application specific (for linear iterative solvers, the basic unit would probably be the number of matrix-vector products). So I'll just avoid catching the MaxCountExceededException. Best regards for now, Sébastien 2011/9/11 Greg Sterijevski <gsterijev...@gmail.com>: > I sent the original to the wrong thread, my apologies! > > Sebastian, > > The only observation I made is in the JIRA notes. Use thread safe > collections for the listener lists. There is a bit of overhead, but if you > have long running optimizations you might want to connect, get the state of > the optimization and then disconnect. > > Thanks, > > -Greg > > 2011/9/9 Sébastien Brisard <sebastien.bris...@m4x.org> > >> Hi, >> I was wondering if anyone of you had the chance to look at the new >> piece of code submitted (JIRA MATH-655). >> Thanks for your comments! >> Sébastien >> >> --------------------------------------------------------------------- >> 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
