Having immutable objects was what I initially had in mind, but I can
live with the other approach. Only, as rightly pointed out by others,
what I had implemented initially was not compatible with
AbstractRealMatrix. The new patch no longer implements getRowDimension()
and getColumnDimension(). If you do not agree with this option, I guess
we only need to remove the "final" keyword from the currently
implemented option. Checks on positivity of the dimensions in the
constructor should also be added, if the constructor is to stay.
This is an interesting discussion, and I learn a lot through it, but I
have to say I haven't got the experience to have a word on which way to
go. So if you just let me know on which option the consensus seems to
settle (since there is apparently no best answer), I'm happy to update
the code accordingly (in two weeks time!).
Best regards,
Sebastien
Le 14/07/11 13:47, Gilles Sadowski a écrit :
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).
Best,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
