[
https://issues.apache.org/jira/browse/MATH-581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13080395#comment-13080395
]
Gilles commented on MATH-581:
-----------------------------
About the usage of the {{ExceptionContext}}, could you start a thread on the
ML? Maybe someone will have a good idea. One of the issue is that the keys
should preferably make sense from the viewpoint of the caller. Hence, as you
said, name like "m" and "a" could be confusing, since they are the parameter
names (in the method definition) and not the argument names (as passed by the
caller).
{quote}
[...] Sorry to waste your time here.
{quote}
Don't apologize; I knew that the comment was lacking... ;)
The idea is that, in general, code is easier to understand (and safer and more
efficient) when as many variables as possible are actually constant
(initialized in the constructor). I think that it's really worth trying to
design classes that are immutable. Of course, this has consequences on the
interactions between classes.
This design issue is also related to the other points: cyclic references and
the role of the "monitor". Unfortunately, I didn't look at the details of yours
classes's relationships, so it's difficult to come up with a concrete
application to this case.
However, one question arises from your previous comment: You use the "monitor"
to
* monitor the computation (for plotting, making backup, ...)
* check the convergence of the algorithm
I'm uncomfortable with these 2 very different things being clumped into one
class, itself being tied to a particular set of classes in a particular package.
Monitoring is a feature that would be useful in many other areas (classes). And
we should not have to re-implement similar thing in each of them. E.g. there
was the same wish from the contributor of the CMA-ES optimizer implementation.
In my opinion, this is also a kind of (advanced) logging, which I'm all for
introducing in CM. However, this would imply an external library dependency,
which is frowned upon by others.
On the other hand, checking for convergence is an integral part of the
algorithm.
There was a similar discussion concerning optimizers (see classes in
"optimization" package): There, the "monitor" is called "ConvergenceChecker":
It might well be that you could reuse it here. It was also the result of a
compromise between an "obvious" stopping criterion (usually tightly linked to
the algorithm) and the potential need for user-defined special criteria
(probably like the tensor condition you evoked).
Concerning the {{StoppingCriterion2}}, I had understood that you were "copying"
the name from somewhere, but it nevertheless does not mean anything. At best,
it could be used for a private inner class, renamed as
"DefaultStoppingCriterion". In books, for pedagogical purposes, they could use
a list of things to demonstrate increasingly better alternatives (I don't know
if that's the case here): so you could have had "BadStoppingCriterion" and then
"GoodStoppingCriterion", which, out of context, would not have made more
sense... :)
> 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
