[
https://issues.apache.org/jira/browse/MATH-581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13080376#comment-13080376
]
Sébastien Brisard commented on MATH-581:
----------------------------------------
Thanks for your comments!
h4. License
OK
h4. Key names
I agree with you, they are not perfect, and more especially not homogeneous (I
forgot to check that I got rid of all "the" prefixes...). Having said that, I
would be happier with self-describing names, as opposed to symbols (a, m).
Should we go for {{vector}}, {{operator}} (for a), and {{preconditioner}} (for
m).
h4. "Couldn't the instance variables be made "final" (and assigned in the
constructors)?"
I do apologize, but I don't understand. Could you be more specific? Sorry to
waste your time here.
h4. Use of {{Incrementor}}
I wasn't aware of its existence. I'm very happy invoking it. My first thought
would be to have the monitor create the incrementor, and return it to the
solver, so that update() would no longer require the iteration number as a
parameter. Also, the way I've implemented it at the moment, the solver *stops*
if the maximum number of iterations is reached, but it is the responsibility of
the user to *check* wether or not the solver stopped because of this
(indicating poor convergence) or because the stopping criterion was fulfilled.
This is not safe, as one may easily forget to check that everything happened
according to the plan...
h4. Cyclic references
That is very true, thanks for pointing that out. What would you suggest (appart
from getting rid of monitors, which I'm not really happy about, see below)?
h4. Is a separate "monitor" class really necessary?
In my view, monitors are a very flexible way to handle CPU intensive iterative
calculations. I should first mention that (IMO) monitors are much more than
stopping criteria. The monitor is called at the end of each iteration, which is
nice for logging purposes (e.g. if you want to plot how fast the algorithm
converges). I also implemented similar monitors for large Monte-Carlo
simulations (more than a week each), and monitors allowed me to schedule easily
periodic backups (which proved to be useful, since the computer which ran the
simulation was actually stopped because the power transformer was flooded...).
Finally, I don't like the idea of imposing the stopping criterion. There are
many stopping criteria around. The only one I've submitted here is quite
general, but you can think of more "physically-oriented" criteria. For example
I'm using these iterative solvers at the moment for mechanical simulations.
Then the stopping criterium could be related to the divergence of the stress
tensor, which must be zero at equilibrium.
I hope I convinced you; if not, maybe we should move this point to the forum?
h4. On {{StoppingCriterion2}}
I knew this would come up... That's why I mentioned in a previous comment that
the "2" comes from the name this stopping criterion received in the
"templates". Maybe I wasn't clear enough. This stopping criterion is a direct
implementation of one of the stopping criteria proposed in _Templates for the
Solution of Linear Systems: Building Blocks for Iterative Methods_.
I guess that the authors had not much more imagination than I had, so they just
numbered the different criteria. For lack of a better idea, I did the same. To
my defense, this is clearly stated in the javadoc; besides, I should mention
that this book is freely available as a PDF file on the web. Anyway, I'm not
dead-locked on this name, so let loose your imagination!!!
> 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
