commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [math] RealLinearOperator and AbstractRealMatrix
Date Wed, 13 Jul 2011 20:52:07 GMT
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,
>>>> 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.

> Gilles
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message