Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of phil.steitz@gmail.com
 designates 74.125.83.171 as permitted sender)
Message-ID: <4E1DC214.4010103@gmail.com>
Date: Wed, 13 Jul 2011 09:04:36 -0700
From: Phil Steitz <phil.steitz@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
 rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [math] RealLinearOperator and AbstractRealMatrix
References: <20110712191202.0F81414045561@svoboda.polytechnique.org>
 <20110713151958.GD3310@dusk.harfang.homelinux.org>
In-Reply-To: <20110713151958.GD3310@dusk.harfang.homelinux.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org