Sébastien, Yes, this is what I had in mind. Others on the list might disagree, but I think paying a bit in performance for some modicum of thread safety in listener/event handling code will make your life simpler.
-Greg 2011/9/11 Sébastien Brisard <sebastien.bris...@m4x.org> > 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 > >
