commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: [math] RealLinearOperator and AbstractRealMatrix
Date Thu, 14 Jul 2011 11:47:13 GMT
Hi S├ębastien.

> 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.

A lot of time has already been devoted to this kind of "silly"
discussions... ;-) Without reaching a definite answer because sometimes it
seems to boil down to a matter of taste.

However, practically, some people (like you) take their time to code new
functionalities with a definite set of use cases in mind. IMHO, those people
should drive the decision towards the most obvious/simple/elegant design
that will achieve their goal. [Notwithstanding slight improvements here and
there so that the style fits in CM, of course ;-).]

Once the initial design is in place, and if a CM user comes with a specific
demand which your code cannot fulfill, we can always start a new discussion.
Currently, I don't think that having "abstract" accessors is the right way
to go because in none of the CM matrix implementations there is a way to
change the dimensionality of the stored data without actually creating
another object. There is also the drive towards having immutable objects
whenever possible and not changing objects in-place; all this goes against
giving the impression (through abstract accessors) that the dimensions of a
linear operator can change during its lifetime.

CM is not a framework (in this case, a data structure framework) for others
to build on; it is primarily a library of algorithms (that operate on
specific data structures defined within CM).


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

View raw message