Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of sebastien.brisard@gmail.com
 designates 209.85.212.43 as permitted sender)
MIME-Version: 1.0
Sender: sebastien.brisard@gmail.com
In-Reply-To: <4E87FDA1.5000409@gmail.com>
References: 
 <CAGRH7Hq7CF4uSUJ6JGvDXAYE063rZoKWQOnLegi74GPaCC66kA@mail.gmail.com>
	<4E877BB0.7020803@gmail.com>
	<CAGRH7Hqm5qd+B3gzU4zfhatmdkK0DmVzP4GcgKQ0tE9reK8Ofw@mail.gmail.com>
	<4E87FDA1.5000409@gmail.com>
Date: Sun, 2 Oct 2011 08:32:23 +0200
Message-ID: 
 <CAGRH7HqWxtG1FyetD79ZtY6mX8mU_T_DPNtqh+k_7eysU+O6ig@mail.gmail.com>
Subject: Re: [math] rename o.a.c.m.linear.SingularMatrixException to
 SingularLinearOperatorException
From: =?ISO-8859-1?Q?S=E9bastien_Brisard?= <sebastien.brisard@m4x.org>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

OK Phil,
I'm just worried about naming consistency. So should I drop "Linear"
everywhere? Only in exception names (where I agree, it's not that
important)?
Thanks,
S=E9bastien

2011/10/2 Phil Steitz <phil.steitz@gmail.com>:
> On 10/1/11 9:42 PM, S=E9bastien Brisard wrote:
>> My mistake! I was convinced we already had
>> =A0 - NonPositiveDefiniteMatrixException extends
>> NonPositiveDefiniteLinearOperatorException
>> =A0 - NonSymmetricMatrixException extends NonSelfAdjointLinearOperatorEx=
ception
>> =A0 - 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. =A0 I don't know about "linear" vs "operator" in
> "LinearOperator" but I think the "linear" can safely be dropped in
> "SingularLinearOperator."
>
> Phil
>>
>> S=E9bastien
>>
>> 2011/10/1 Phil Steitz <phil.steitz@gmail.com>:
>>> On 10/1/11 1:21 AM, S=E9bastien 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. =A0The 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. =A0Of 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. =A0Therefore 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). =A0I would also
>>> shorten the name to SingularOperatorException.
>>>
>>> Phil
>>>> S=E9bastien
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>
>

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