commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sébastien Brisard <>
Subject Re: [math] RealLinearOperator and AbstractRealMatrix
Date Thu, 14 Jul 2011 06:08:04 GMT
Happy 14th of July to all!
OK, from what I understand, the patch I submitted yesterday does not 
comply with your requirements, as I provided a constructor for 
RealLinearOperator, with dimensions of the domain and codomain as 
parameters. Implicitely, I intended these to be fixed for the whole life 
of the object. So, attached to JIRA MATH-581 is patch #05, with 
following changes
   - getRowDimension() and getColumnDimension() are now abstract
   - constructor has been removed.
I think this is faithful to what I understood from the discussion.
However, I have now a question on the whole design, as I do not want to 
do the same errors twice. I initially submitted RealLinearOperator as an 
interface, but it was required to get rid of it, to the benefit of 
abstract classes. That's fine, but the abstract class now does next to 
nothing. My implementation of
double[] operate(double[])
based on
RealVector operate(RealVector)
is really for lazy people who can't be bothered when extending 
RealLinearOperator. But we could have done without this default 
implementation. We would then have had an empty abstract class. So why 
not an interface? As I said, I want to learn, not to be controversial.
Also, I'd like to apologize for these multiple corrections of an albeit 
simple set of classes. I hope I didn't waste to much of your time.

Le 14/07/11 00:01, Ted Dunning a écrit :
> Actually, this is a major issue.
> Take, for instance, the example of considering a Lucene index as a linear
> operator.  The number of rows is the number of documents (which is changing
> as documents are added) and the number of columns is the number of unique
> terms (which is also changing as documents are added).
> Matrix multiplication consists of translating a (hopefully sparse) vector
> into a query, running the query and interpreting the result as a (sparse)
> vector.
> This is just one of a host of similar application oriented definitions of a
> LinearOperator, none of which define the number of rows and columns at
> construction time.
> I can still do a singular value decomposition of this linear operator
> On Wed, Jul 13, 2011 at 1:52 PM, Phil Steitz<>  wrote:

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

View raw message