You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Sébastien Brisard <se...@m4x.org> on 2011/07/06 08:32:14 UTC

Iterative linear solvers (MATH-581) again

Good morning,
my proposal for the implementation of linear iterative solvers (JIRA MATH-581)
has raised some comments from Gilles and Luc, but I think no consensus has
been reached on one issue raised by Gilles. Before submitting a new version of
the corresponding classes, I'd like to make a new proposal.

Here is the thing. I have defined two exceptions, namely
  - NonSelfAdjointLinearOperatorException
  - NonPositiveDefiniteLinearOperatorException,
the latter being typically raised when a vector x is found, such as x'.A.x <=
0, where A is the linear operator under consideration.

Now, the constructor of this exception takes as input A and x (which I call
the "offending vector"). There is a method to return a reference to A (which
is a RealLinearOperator), and a method to return a deep copy of x, the reason
for this is that x can either be a double[], or a RealVector.

I agree with Gilles, for debugging purposes, it would probably be better to be
able to trace the offending vector, hence to have the exception return a
reference to this offending vector. But this is just not possible, since there
is no unique type for this vector. Gilles pointed out that there is the method
getData() in RealVector which would do the job, but there is no requirement in
the contract of this method for this to be a shallow/deep copy. Is this a
concern ? If not, then I could change the current method
void copyOffendingVector(final double[] x)
(where x is modified)
into
double[] getOffendingVector()
but we would lose the track of the actual object which first raised the
exception.

Another option would be to have the method getOffendingVector() return an
Object, and try to cast it to a RealVector or a double[] when catching the
exception. Not too sure it's good practice to return Objects, though.

I'm looking forward to reading your comments, and will update the sources
accordingly.

Sebastien

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org