[ https://issues.apache.org/jira/browse/MATH581?page=com.atlassian.jira.plugin.system.issuetabpanels:commenttabpanel&focusedCommentId=13080759#comment13080759
]
Sébastien Brisard commented on MATH581:

* On the use of {{ExceptionContext}}: I'll start a thread
* Some (minor naming issues). I think [this threadhttp://mailarchives.apache.org/mod_mbox/commonsdev/201108.mbox/<CAGRH7HobnHhmmd9D=e7p1nWGLsHm_Gs9QXh93__axAhOnnQ@mail.gmail.com>]
on the ML confirmed that the following changes could be operated
** {{AbstractIterativeLinearSolver}} > {{IterativeLinearSolver}},
** {{AbstractPreconditionedIterativeLinearSolver}} > {{PreconditionedIterativeLinearSolver}},
** {{AbstractIterativeLinearSolverMonitor}} > {{IterativeLinearSolverMonitor}}, provided
of course that this class stays in the end,
** {{StoppingCriterion2}} > {{BasicStoppingCriterion}} (sorry for the lack of imagination,
but maybe this new name will better suit your taste?).
* Cyclic references and all that. The problem is both solver and monitor need to know about
the other. I think {{IterativeLinearSolverMonitor}} are very related to {{java.util.EventListener}}.
As far as I remember, these things work as follows
** the listener is first registered by the component, e.g.
{code:java}
java.awt.Component.addFooListener(FooListener l)
{code}
** each time an event occurs, the component calls the listener
{code:java}
java.awt.Component.fireFooEventOccured(FooEvent event)
{code}
** The listener catches the event, and can retrieve the component from which it originates
by the following method
{code:java}
java.util.EventObject.getSource()
{code}
At some point, I considered implementing monitors with exactly the same (rather neat) pattern,
but considered it was probably "a jackhammer to drive a nail". However, if we want to make
monitors more general, maybe that would be the way to go. And actually, we could probably
reuse the very same object definitions (I guess the objects in java.util are intended to be
more general than simply AWT/Swing). In any case, this is how the cyclic reference problem
is avoided in AWT. What do you think of such a solution?
* Stopping criterion. Ah! I see we have different views on this, but I take your point: objects
should be confined to welldefined tasks (if I understood you correctly). I considered using
the existing {{o.a.c.m.optimization.ConvergenceChecker}}, but in my view, the implementation
is too restrictive, since convergence is explicitely checked based on the last two iterations.
Some convergence checks only require the last iteration, so I could not see any way out. But
I think it would be very nice to have a kind of general crosspackage implementation of stopping
criteria at large.
* Immutability. I guess that what you would like to have the following lines of code
{code:java}
IterativeLinearSolver solver = new ConjugateGradient(a, monitor, true);
solver.solve(b, x);
{code}
by
{code:java}
IterativeLinearSolver solver = new ConjugateGradient(a, b, x, monitor, true);
xx = solver.solve();
{code}
Please note that x has to be specified (initial guess) in the constructor. I gather that immutability
is a very safe way of doing things. I'm just worried about the fact that it leads to copying
objects (e.g. vectors), which can be quite large (since iterative linear solvers are used
to solve large systems). Do you see this as an issue? Should we even consider it? I am not
even thinking of the time issue, but rather of the memory issue.
> Support for iterative linear solvers
> 
>
> Key: MATH581
> URL: https://issues.apache.org/jira/browse/MATH581
> Project: Commons Math
> Issue Type: New Feature
> Affects Versions: 3.0, Nightly Builds
> Reporter: Sébastien Brisard
> Labels: iterative, linear, solver
> Attachments: MATH58101.patch, MATH58102.zip, MATH58103.zip, MATH58104.zip,
MATH58105.patch, MATH58105.patch, conjugategradient.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 commonsmath. The beauty of these
solvers is that they do not need direct access to the coefficients of the matrix, only matrixvector
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:
matrixvector 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
