commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: [math] Iterative linear solvers (MATH-581) again
Date Fri, 08 Jul 2011 10:06:28 GMT
Le 08/07/2011 08:44, Sebastien Brisard a écrit :
> Hi everyone,
> well the message below did not raise much of an interest... My apology, I
> forgot to quote [math] in the title.

Sorry, I forgot to reply in a timely fashion.

> Anyway, I have a new proposal regarding this issue. I do not know what your
> view on the subject is, but I tend to think that exceptions should return
> references and not deep copies of the objects that caused these exceptions to
> be raised. This facilitates debugging (I guess), and also helps identify the
> exact origin of the problem, without having to specialize the exception. As an

Yes, exception are targeted towards handling of ... exceptional cases, 
not heavy duty use during normal production. As such, they should not be 
over-optimized for speed.

> example, Conjugate Gradient requires positive definiteness of both matrix (a)
> and preconditioner (m). If a NonPositiveDefiniteLinearOperatorException is
> caught, then I can simply test
> a == e.getOffendingLinearOperator()
> or
> m = e.getOffendingLinearOperator()
> Now, coming to offending vectors, the issue is that these can either be
> instances of RealVector, or double[]. So, what type should be returned by
> getOffendingVector()?
> I propose to have the exceptions return a reference to the RealVector. If the
> exception was raised with a double[], then the returned RealVector will
> actually be an instance of ArrayRealVector, with a reference to the initial
> double[]. All this is to be clearly specified in the javadoc. Does that sound
> like a viable option?

I would go to the natural type we get when building the exception. If we 
may build the exception from both types, then I would select RealVector. 
We do not intend to perform large processing on elements, but we want to 
display them and I think we do have formatting for vectors.

best regards,

> I'll attach the corresponding files to the JIRA issue, if you want to have a
> more precise idea of what I'm talking about.
> Thanks in advance for your comments,
> Sebastien
>> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message