commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sébastien Brisard <>
Subject Re: [math] Monitoring iterative algorithms
Date Sun, 11 Sep 2011 14:58:22 GMT
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,

2011/9/11 Greg Sterijevski <>:
> 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 <>
>> 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:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message