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: local policy)
Date: Wed, 13 Jul 2011 23:08:01 +0200
From: Gilles Sadowski <gilles@harfang.homelinux.org>
To: dev@commons.apache.org
Subject: Re: [math] RealLinearOperator and AbstractRealMatrix
Message-ID: <20110713210801.GT10648@dusk.harfang.homelinux.org>
Mail-Followup-To: dev@commons.apache.org
References: <20110712191202.0F81414045561@svoboda.polytechnique.org>
 <20110713151958.GD3310@dusk.harfang.homelinux.org>
 <4E1DC214.4010103@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <4E1DC214.4010103@gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-DCC-scarlet.be-Metrics: eir 20002; Body=1 Fuz1=1 Fuz2=1
X-Virus-Scanned: clamav-milter 0.97.1-exp at eir
X-Virus-Status: Clean
X-Virus-Checked: Checked by ClamAV on apache.org

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?


Gilles

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