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 16:04:36 GMT
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.

>> 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:
> For additional commands, e-mail:

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

View raw message