On 7/13/11 8:19 AM, Gilles Sadowski wrote: > Hi. > >> [...] >> Before I commit new code (Conjugate gradient, SYMMLQ, etc...), I'll open a >> new >> JIRA ticket for having AbstractRealMatrix inherit from RealLinearOperator, if >> that's OK with everyone. > Currently this is not possible because the > getRowDimension > getColumnDimension > are declared "final" in "RealLinearOperator" but are "abstract" in > "AbstractRealMatrix". > > So there are 2 questions, one for you and the other for the designer(s) of > "AbstractRealMatrix" and its subclasses: > > 1. Do you think that the two methods must be "final"? > 2. Why were the row and column dimensions stored in each subclass and not in > the parent class?
So they do not necessarily have to be "stored" at all - i.e., some representations may wish to compute these values (as most current impls do. See, e.g. the array-based real matrices. The row and column dimensions are not stored as instance data in these classes.) Forcing every impl to maintain them does not sound good, especially since there are no setters and the fields are private in the parent. Definitely better to either imitate the setup in AbstractRealMatrix (dispense with the fields and define abstract getters) or make the getXxDimension methods either abstract or at least non-final. My recommendation would be to follow the model of AbstractRealMatrix: a) no instance fields for dimensions b) abstract dimension getters c) protected constructor that just checks positivity. Phil > >> Because MATH-581 got a bit messy, I'll also open a new one specifically with >> these new classes (again, if that suits you). > I don't think that it's necessary; better keep everything in the same place > and resolve the issue when the functionality is working as intended. > >> Also, I'd like to have your feeling on MATH-613, so that I can submit the >> corresponding code (which would in turn lead to a more compact CG/SYMMLQ...). > Let's go with "combine" and "combineToSelf" first. > I like the "functional" generalization but it can be added later (as "map" > and "mapToSelf"). > > > Regards, > Gilles > > --------------------------------------------------------------------- > 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
