On 7/13/11 2:08 PM, Gilles Sadowski wrote: > On Wed, Jul 13, 2011 at 09:04:36AM -0700, Phil Steitz wrote: >> 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. > I've looked at the implementations, hence my question. > The data arrays are assigned at construction; so it seems that the idea is > that the dimensions are known and fixed at construction. Also, submatrix > assignment is allowed only within those fixed dimensions. Consequently, I > don't see the advantage of computing what is already known. > > The way the data is stored does not change the mathematical abstraction that > a matrix is defined by specifying the number of rows and the number of > columns. Why shouldn't these two numbers be stored at the most abstract > level? > > Following the rationale provided by Sébastien, the linear operators will > allow matrix computations without storing the matrix data. In this case, > could the dimensions change once the object is created, or are they fixed as > well? In the latter case, why would you want to override the getters? > >> 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. > What is the use-case for such a complicated setup?
I actually see adding instance fields as the more complicated setup :) You then have to make the super() constructor calls all the time to get the instance fields set and you have to chase through more layers to find them. I agree with the idea that the properties should be exposed at the top level and I like the basic setup, just don't like having abstract superclasses define fields when they don't need to (pretty much for the reasons Ted gave). This is not a huge issue, though, so I can live with it if you feel strongly that the fields should be persisted at the top level. Phil > > > 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
