[
https://issues.apache.org/jira/browse/MATH-581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13080954#comment-13080954
]
Gilles commented on MATH-581:
-----------------------------
{quote}
The problem is both solver and monitor need to know about the other.
{quote}
In your design, yes. My proposal in to change it so that the solver will pass
the necessary information to the "Monitor", akin to what is done in the
optimizers + {{ConvergenceChecker}}.
The monitor should not be able to alter the state of the solver.
At least, that is for the "checking" part which IMO should be a separate and
quite small class.
For the real "monitor" part, you should really start a thread on the ML. I
would be against the multiple special-purpose monitors tied to a specific
algorithm. We must think of something generally applicable to all CM. That
won't be trivial, and I'd leave that part out of the code which you are
currently designing.
An alternative to using classes from "awt" or "swing", there is the
{{java.util.Observable}} class which might be the basis for a CM monitoring
feature.
{quote}
Some convergence checks only require the last iteration,
{quote}
Nothing forces you to use both arguments!
It would be beneficial that we find some common ground for checking convergence
in different areas of CM. Maybe that from the point-of-view of iterative
solvers, we can modify {{ConvergenceChecker}} so that it will become more
flexible (i.e. applicable to both areas). Please post a message on the ML
exposing your requirements and how {{ConvergenceChecker}} should be changed to
fulfill them.
{quote}
Immutability. I guess that what you would like to have [...]
{quote}
Actually, no. The main issue is how to best separate the attributes of the
algorithm from attributes of the data. Admittedly, there is a lot of
subjectivity here. For example, see the current implementation of the root
solvers (which itself was refactored to look like what was done for the
optimizers).
So, in your case, a wild guess would be:
{code}
final IterativeLinearSolver solver = new ConjugateGradient(monitor);
xx = solver.solve(a, b, x, true);
{code}
Thus the "ConjugateGradient" instance is reusable: You don't need a new
instance to solve different problems, represented by different input data. But
I would associate the checker with the algorithm.
There is no clear-cut line; IMO, it must be a compromise between full
procedural style (everything passed to the method) and full OO (but not
necessarily good OO) style (everything passed to the constructors or through
setters).
> Support for iterative linear solvers
> ------------------------------------
>
> Key: MATH-581
> URL: https://issues.apache.org/jira/browse/MATH-581
> Project: Commons Math
> Issue Type: New Feature
> Affects Versions: 3.0, Nightly Builds
> Reporter: Sébastien Brisard
> Labels: iterative, linear, solver
> Attachments: MATH-581-01.patch, MATH-581-02.zip, MATH-581-03.zip,
> MATH-581-04.zip, MATH-581-05.patch, MATH-581-05.patch,
> conjugate-gradient.zip, exceptions.patch, linearoperator.zip
>
>
> Dear all,
> this issue has already been discussed on the forum. The idea is to implement
> the most popular linear iterative solvers (CG, SYMMLQ, etc...) in
> commons-math. The beauty of these solvers is that they do not need direct
> access to the coefficients of the matrix, only matrix-vector products are
> necessary. This is goof, as sometimes it is inetficient to store the
> coefficients of the matrix.
> So basically, before implementing the iterative solvers, we need to define an
> interface slightly more general than a matrix, namely LinearOperator, with
> only one basic operation: matrix-vector product.
> Here are a few interfaces and abstract classes that do that. Nothing fancy
> yet, I just wanted to have you advice on the implementation before I commit
> some solvers.
> I thought these classes could go in a package
> org.apache.commons.math.linearoperator, but really, I haven't got a clue...
> Best regards,
> Sebastien
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
