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/10/01 10:21:00 UTC
[math] rename o.a.c.m.linear.SingularMatrixException to SingularLinearOperatorException
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?
Sébastien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] rename o.a.c.m.linear.SingularMatrixException to SingularLinearOperatorException
Posted by Sébastien Brisard <se...@m4x.org>.
Done in rev r1178306.
Best regards,
Sébastien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] rename o.a.c.m.linear.SingularMatrixException to SingularLinearOperatorException
Posted by Sébastien Brisard <se...@m4x.org>.
2011/10/2 Phil Steitz <ph...@gmail.com>:
> On 10/2/11 7:38 AM, Gilles Sadowski wrote:
>> Hello.
>>
>>> took me some time to figure out what your [1] meant, but I think I got
>>> it (or did I?)... I'm a bit on the slow side.
>> The first time I saw this quote, it also took me a lot of time to understand
>> what they were talking about. Indeed, the mere fact of having a hard time
>> understanding it indicates that the quote perfectly illustrates the point!
>> :-)
>>
>>>> +1 also because it is the standard style in Java (for better or worse).
>>>>
>>>> As I've pointed out somewhere else[2], to avoid an avalanche of exception
>>>> classes[3], the default assumption should probably not be that every concept
>>>> embodied in a Java class must have its own set of subsumed exceptions.
>>>> Rather, failures are more of a concern that is cross-cutting along possibly
>>>> unrelated (algorithm) classes. E.g. even if an operator is not always a
>>>> linear operator, couldn't it be that using one or the other could trigger a
>>>> "SingularOperatorException" (where the "ExceptionContext" would be used to
>>>> more fully describe the specifics of each case)?
>>>>
>>> I understand that appropriate use of exceptions is in fact a quite
>>> delicate design issue, which is far beyond my designing skills, so I'm
>>> ready to take anything which sounds good to more experienced people.
>>> Only, in the present case, I have a hard time figuring out from the
>>> above discussion what *is* the best solution.
>>>
>>> If I understood correctly, Phil would like to have two separate
>>> exceptions, SingularOperatorException and SingularMatrixException,
>>> with no inheritance link
>> Conceptually, the exception are related; however, as we already discussed,
>> it is difficult to make them share an implementation.
>> It would have been possible by having (marker) interfaces, but that seems to
>> be overkill for something that most of the time ends up in aborting the
>> program...
>>
>>> Gilles leans on the one exception+context side (since a Matrix is a
>>> linear operator therefore an operator). So if I understand Gilles
>>> correctly, we would rename SingularMatrixException to
>>> SingularOperatorException, and throw this exception each time we try
>>> to invert an operator in the widest sense (linear or not, matrix or
>>> not). I actually like that simple option. Also, I would like to remind
>>> you that the present exception does *nothing* but display a standard
>>> message (there is no state variable in the present
>>> SingularMatrixException).
>>>
>>> Do you think that the discussion is well summed up?
>> Almost (cf. below).
>>
>>> Or can you think
>>> of a better way to implement things? For the time, I see two options
>>> 1. Keep SingularMatrixException, add SingularOperatorException
>
> +1 for the reasons I gave above.
> +1 for leaving the "linear" in the other names.
>
> Phil
>>> 2. Rename SingularMatrixException to SingularOperatorException and use
>>> it more widely (and possibly move it to a more general package). Use
>>> context if needed.
>>> 3. any other idea?
>> I hadn't thought of it, but in the line of "leaner is better", I like
>> number 2. However, in some application contexts, people would probably
>> prefer to keep the "Matrix" part of the exception name, thus number 1.
>>
>>
>> Best,
>> Gilles
>>
>> ---------------------------------------------------------------------
>> 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
>
>
OK, I'll commit something along these lines. Thank you everyone for your advice!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] rename o.a.c.m.linear.SingularMatrixException to SingularLinearOperatorException
Posted by Phil Steitz <ph...@gmail.com>.
On 10/2/11 7:38 AM, Gilles Sadowski wrote:
> Hello.
>
>> took me some time to figure out what your [1] meant, but I think I got
>> it (or did I?)... I'm a bit on the slow side.
> The first time I saw this quote, it also took me a lot of time to understand
> what they were talking about. Indeed, the mere fact of having a hard time
> understanding it indicates that the quote perfectly illustrates the point!
> :-)
>
>>> +1 also because it is the standard style in Java (for better or worse).
>>>
>>> As I've pointed out somewhere else[2], to avoid an avalanche of exception
>>> classes[3], the default assumption should probably not be that every concept
>>> embodied in a Java class must have its own set of subsumed exceptions.
>>> Rather, failures are more of a concern that is cross-cutting along possibly
>>> unrelated (algorithm) classes. E.g. even if an operator is not always a
>>> linear operator, couldn't it be that using one or the other could trigger a
>>> "SingularOperatorException" (where the "ExceptionContext" would be used to
>>> more fully describe the specifics of each case)?
>>>
>> I understand that appropriate use of exceptions is in fact a quite
>> delicate design issue, which is far beyond my designing skills, so I'm
>> ready to take anything which sounds good to more experienced people.
>> Only, in the present case, I have a hard time figuring out from the
>> above discussion what *is* the best solution.
>>
>> If I understood correctly, Phil would like to have two separate
>> exceptions, SingularOperatorException and SingularMatrixException,
>> with no inheritance link
> Conceptually, the exception are related; however, as we already discussed,
> it is difficult to make them share an implementation.
> It would have been possible by having (marker) interfaces, but that seems to
> be overkill for something that most of the time ends up in aborting the
> program...
>
>> Gilles leans on the one exception+context side (since a Matrix is a
>> linear operator therefore an operator). So if I understand Gilles
>> correctly, we would rename SingularMatrixException to
>> SingularOperatorException, and throw this exception each time we try
>> to invert an operator in the widest sense (linear or not, matrix or
>> not). I actually like that simple option. Also, I would like to remind
>> you that the present exception does *nothing* but display a standard
>> message (there is no state variable in the present
>> SingularMatrixException).
>>
>> Do you think that the discussion is well summed up?
> Almost (cf. below).
>
>> Or can you think
>> of a better way to implement things? For the time, I see two options
>> 1. Keep SingularMatrixException, add SingularOperatorException
+1 for the reasons I gave above.
+1 for leaving the "linear" in the other names.
Phil
>> 2. Rename SingularMatrixException to SingularOperatorException and use
>> it more widely (and possibly move it to a more general package). Use
>> context if needed.
>> 3. any other idea?
> I hadn't thought of it, but in the line of "leaner is better", I like
> number 2. However, in some application contexts, people would probably
> prefer to keep the "Matrix" part of the exception name, thus number 1.
>
>
> Best,
> Gilles
>
> ---------------------------------------------------------------------
> 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
Re: [math] rename o.a.c.m.linear.SingularMatrixException to
SingularLinearOperatorException
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hello.
> took me some time to figure out what your [1] meant, but I think I got
> it (or did I?)... I'm a bit on the slow side.
The first time I saw this quote, it also took me a lot of time to understand
what they were talking about. Indeed, the mere fact of having a hard time
understanding it indicates that the quote perfectly illustrates the point!
:-)
> >
> > +1 also because it is the standard style in Java (for better or worse).
> >
> > As I've pointed out somewhere else[2], to avoid an avalanche of exception
> > classes[3], the default assumption should probably not be that every concept
> > embodied in a Java class must have its own set of subsumed exceptions.
> > Rather, failures are more of a concern that is cross-cutting along possibly
> > unrelated (algorithm) classes. E.g. even if an operator is not always a
> > linear operator, couldn't it be that using one or the other could trigger a
> > "SingularOperatorException" (where the "ExceptionContext" would be used to
> > more fully describe the specifics of each case)?
> >
> I understand that appropriate use of exceptions is in fact a quite
> delicate design issue, which is far beyond my designing skills, so I'm
> ready to take anything which sounds good to more experienced people.
> Only, in the present case, I have a hard time figuring out from the
> above discussion what *is* the best solution.
>
> If I understood correctly, Phil would like to have two separate
> exceptions, SingularOperatorException and SingularMatrixException,
> with no inheritance link
Conceptually, the exception are related; however, as we already discussed,
it is difficult to make them share an implementation.
It would have been possible by having (marker) interfaces, but that seems to
be overkill for something that most of the time ends up in aborting the
program...
> Gilles leans on the one exception+context side (since a Matrix is a
> linear operator therefore an operator). So if I understand Gilles
> correctly, we would rename SingularMatrixException to
> SingularOperatorException, and throw this exception each time we try
> to invert an operator in the widest sense (linear or not, matrix or
> not). I actually like that simple option. Also, I would like to remind
> you that the present exception does *nothing* but display a standard
> message (there is no state variable in the present
> SingularMatrixException).
>
> Do you think that the discussion is well summed up?
Almost (cf. below).
> Or can you think
> of a better way to implement things? For the time, I see two options
> 1. Keep SingularMatrixException, add SingularOperatorException
> 2. Rename SingularMatrixException to SingularOperatorException and use
> it more widely (and possibly move it to a more general package). Use
> context if needed.
> 3. any other idea?
I hadn't thought of it, but in the line of "leaner is better", I like
number 2. However, in some application contexts, people would probably
prefer to keep the "Matrix" part of the exception name, thus number 1.
Best,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] rename o.a.c.m.linear.SingularMatrixException to SingularLinearOperatorException
Posted by Sébastien Brisard <se...@m4x.org>.
2011/10/2 Gilles Sadowski <gi...@harfang.homelinux.org>:
> Hi Sébastien.[1]
>
Hi Gilles,
took me some time to figure out what your [1] meant, but I think I got
it (or did I?)... I'm a bit on the slow side.
>
> +1 also because it is the standard style in Java (for better or worse).
>
> As I've pointed out somewhere else[2], to avoid an avalanche of exception
> classes[3], the default assumption should probably not be that every concept
> embodied in a Java class must have its own set of subsumed exceptions.
> Rather, failures are more of a concern that is cross-cutting along possibly
> unrelated (algorithm) classes. E.g. even if an operator is not always a
> linear operator, couldn't it be that using one or the other could trigger a
> "SingularOperatorException" (where the "ExceptionContext" would be used to
> more fully describe the specifics of each case)?
>
I understand that appropriate use of exceptions is in fact a quite
delicate design issue, which is far beyond my designing skills, so I'm
ready to take anything which sounds good to more experienced people.
Only, in the present case, I have a hard time figuring out from the
above discussion what *is* the best solution.
If I understood correctly, Phil would like to have two separate
exceptions, SingularOperatorException and SingularMatrixException,
with no inheritance link
Gilles leans on the one exception+context side (since a Matrix is a
linear operator therefore an operator). So if I understand Gilles
correctly, we would rename SingularMatrixException to
SingularOperatorException, and throw this exception each time we try
to invert an operator in the widest sense (linear or not, matrix or
not). I actually like that simple option. Also, I would like to remind
you that the present exception does *nothing* but display a standard
message (there is no state variable in the present
SingularMatrixException).
Do you think that the discussion is well summed up? Or can you think
of a better way to implement things? For the time, I see two options
1. Keep SingularMatrixException, add SingularOperatorException
2. Rename SingularMatrixException to SingularOperatorException and use
it more widely (and possibly move it to a more general package). Use
context if needed.
3. any other idea?
Looking forward to hearing your favored choice,
Sébastien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] rename o.a.c.m.linear.SingularMatrixException to
SingularLinearOperatorException
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hi Sébastien.[1]
On Sun, Oct 02, 2011 at 01:34:50PM +0200, Sébastien Brisard wrote:
> Right. I tend to like self-describing names also good. In french
> (you've rightly spotted a non-native speaker...), an "operator" is not
> necessarily linear, and I think same goes to english terminology
> (could you confirm please). So a linear operator is not exactly
> identical to an operator.
> However, as Phil pointed out, the distinction does not really matter
> when it goes to exceptions. So maybe I could replace LinearOperator
> with Operator in exception names. For other classes, with more
> mathematical meaning, we could keep LinearOperator, even if it makes
> for very long names. Would that suit everyone?
> Sébastien
>
> 2011/10/2 Ted Dunning <te...@gmail.com>:
> > On Sat, Oct 1, 2011 at 10:58 PM, Phil Steitz <ph...@gmail.com> wrote:
> >
> >> > 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."
> >
> >
> > Abbreviations don't really shorten names. They just make them impossible
> > for non-native speakers to guess. And if abbreviations are done by
> > non-native speakers, they become impossible for anybody to guess.
> >
> > +1 to avoiding abbreviations where possible.
+1 also because it is the standard style in Java (for better or worse).
As I've pointed out somewhere else[2], to avoid an avalanche of exception
classes[3], the default assumption should probably not be that every concept
embodied in a Java class must have its own set of subsumed exceptions.
Rather, failures are more of a concern that is cross-cutting along possibly
unrelated (algorithm) classes. E.g. even if an operator is not always a
linear operator, couldn't it be that using one or the other could trigger a
"SingularOperatorException" (where the "ExceptionContext" would be used to
more fully describe the specifics of each case)?
[1] A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
[2] https://issues.apache.org/jira/browse/MATH-485
[3] This is the same problem as the numerous error messages in the
"LocalizedFormats" enum.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] rename o.a.c.m.linear.SingularMatrixException to SingularLinearOperatorException
Posted by Sébastien Brisard <se...@m4x.org>.
Right. I tend to like self-describing names also good. In french
(you've rightly spotted a non-native speaker...), an "operator" is not
necessarily linear, and I think same goes to english terminology
(could you confirm please). So a linear operator is not exactly
identical to an operator.
However, as Phil pointed out, the distinction does not really matter
when it goes to exceptions. So maybe I could replace LinearOperator
with Operator in exception names. For other classes, with more
mathematical meaning, we could keep LinearOperator, even if it makes
for very long names. Would that suit everyone?
Sébastien
2011/10/2 Ted Dunning <te...@gmail.com>:
> On Sat, Oct 1, 2011 at 10:58 PM, Phil Steitz <ph...@gmail.com> wrote:
>
>> > 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."
>
>
> Abbreviations don't really shorten names. They just make them impossible
> for non-native speakers to guess. And if abbreviations are done by
> non-native speakers, they become impossible for anybody to guess.
>
> +1 to avoiding abbreviations where possible.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] rename o.a.c.m.linear.SingularMatrixException to SingularLinearOperatorException
Posted by Ted Dunning <te...@gmail.com>.
On Sat, Oct 1, 2011 at 10:58 PM, Phil Steitz <ph...@gmail.com> wrote:
> > 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."
Abbreviations don't really shorten names. They just make them impossible
for non-native speakers to guess. And if abbreviations are done by
non-native speakers, they become impossible for anybody to guess.
+1 to avoiding abbreviations where possible.
Re: [math] rename o.a.c.m.linear.SingularMatrixException to SingularLinearOperatorException
Posted by Sébastien Brisard <se...@m4x.org>.
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ébastien
2011/10/2 Phil Steitz <ph...@gmail.com>:
> 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 <ph...@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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] rename o.a.c.m.linear.SingularMatrixException to SingularLinearOperatorException
Posted by Phil Steitz <ph...@gmail.com>.
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 <ph...@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
Re: [math] rename o.a.c.m.linear.SingularMatrixException to SingularLinearOperatorException
Posted by Sébastien Brisard <se...@m4x.org>.
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...
Sébastien
2011/10/1 Phil Steitz <ph...@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
Re: [math] rename o.a.c.m.linear.SingularMatrixException to SingularLinearOperatorException
Posted by Phil Steitz <ph...@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