commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles (JIRA)" <>
Subject [jira] [Commented] (MATH-581) Support for iterative linear solvers
Date Mon, 08 Aug 2011 14:04:27 GMT


Gilles commented on MATH-581:

The problem is both solver and monitor need to know about the other.

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.

Some convergence checks only require the last iteration,

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

Immutability. I guess that what you would like to have [...]

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:
final IterativeLinearSolver solver = new ConjugateGradient(monitor);
xx = solver.solve(a, b, x, true);
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:
>             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-05.patch, MATH-581-05.patch,, exceptions.patch,
> 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:


View raw message