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.ste...@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-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
