commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [math] rename o.a.c.m.linear.SingularMatrixException to SingularLinearOperatorException
Date Sun, 02 Oct 2011 05:58:57 GMT
On 10/1/11 9:42 PM, Sébastien Brisard wrote:
> My mistake! I was convinced we already had
>   - NonPositiveDefiniteMatrixException extends
> NonPositiveDefiniteLinearOperatorException
>   - 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...

I like full words.   I don't know about "linear" vs "operator" in
"LinearOperator" but I think the "linear" can safely be dropped in
"SingularLinearOperator." 

Phil
>
> Sébastien
>
> 2011/10/1 Phil Steitz <phil.steitz@gmail.com>:
>> 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: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


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


Mime
View raw message