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

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 selfdescribing
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 MonteCarlo
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
"physicallyoriented" 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 deadlocked on this name, so let loose your imagination!!!
> 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
