commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles (JIRA)" <>
Subject [jira] [Commented] (MATH-581) Support for iterative linear solvers
Date Sat, 06 Aug 2011 10:59:27 GMT


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).

[...] Sorry to waste your time here.
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:
>             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-05.patch, MATH-581-05.patch,, exceptions.patch,
> 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:


View raw message