commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Sterijevski <gsterijev...@gmail.com>
Subject Re: [math] Monitoring iterative algorithms
Date Tue, 13 Sep 2011 05:06:31 GMT
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.brisard@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 <gsterijevski@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.brisard@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-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message