[
https://issues.apache.org/jira/browse/MATH-581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13080759#comment-13080759
]
Sébastien Brisard commented on MATH-581:
----------------------------------------
* On the use of {{ExceptionContext}}: I'll start a thread
* Some (minor naming issues). I think [this
thread|http://mail-archives.apache.org/mod_mbox/commons-dev/201108.mbox/<CAGRH7HobnHhmmd9D=e-7p1nwg-lshm_gs9qxh93__axaho-...@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 well-defined 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 cross-package 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: 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
