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