commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sébastien Brisard <>
Subject Re: [math] rename o.a.c.m.linear.SingularMatrixException to SingularLinearOperatorException
Date Sun, 02 Oct 2011 04:42:10 GMT
My mistake! I was convinced we already had
  - NonPositiveDefiniteMatrixException extends
  - NonSymmetricMatrixException extends NonSelfAdjointLinearOperatorException
  - NonSquareMatrixException extends NonSquareLinearOperatorException
but looking at the javadoc, this is not the case. So I agree, your
third option would be the simplest.

As for shortening the name, I'm all for it. For consistency, I would
do it for every class matching the pattern *LinearOperator* if you all
agree. Also, I think that "linear" is as important as "operator" in
"LinearOperator" (even if lilnearity might seem an obvious feature,
provided all the classes we are discussing are actually located in the
linear package). So what do you think of LinOp as a compromise?
Something like RealLinOp instead of RealLinearOperator,
NonSquareLinOpException, etc...


2011/10/1 Phil Steitz <>:
> On 10/1/11 1:21 AM, Sébastien Brisard wrote:
>> Hello,
>> I need to be able to throw an exception when an iterative linear
>> solver detects that a RealLinearOperator is singular. I would propose
>> to implement a SingularLinearOperatorException. Then, since RealMatrix
>> is derived from RealLinearOperator, it would be logical to have
>> SingularMatrixException inherit from SingularLinearOperatorException.
>> However, looking at the present impl of SingularMatrixException, this
>> exception does nothing fancy. So having two different exceptions might
>> be too much, I don't know.
>> So here are two proposals
>> 1. Rename SingularMatrixException to SingularLinearOperatorException
>> 2. Create SingularLinearOperatorException, and have
>> SingularMatrixException extend SingularLinearOperatorException.
>> Which option (or any other) do you favor?
> I would keep it simple and just have the two exceptions
> independent.  The reason for this is that the activation contexts
> are likely to not often have much in common - i.e., as we have
> discussed before, a singular matrix exception will be triggered when
> a matrix that is not supposed to be singular is numerically singular
> (usually with some kind of threshold) while a singular operator
> exception is going to be triggered when an operator acts
> singularly.  Of course, if the operator is represented by a matrix,
> then the specialization makes sense; but this will not always be the
> case, so there is not going to be meaningful state or implementation
> inheritance.  Therefore I don't see much value in the inheritance
> (think about the value of catching the superclass or inheritance of
> state or implementation in the exceptions themselves).  I would also
> shorten the name to SingularOperatorException.
> Phil
>> Sébastien
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message