commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sébastien Brisard <sebastien.bris...@m4x.org>
Subject Re: [math] RealLinearOperator and AbstractRealMatrix
Date Thu, 14 Jul 2011 11:47:16 GMT
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-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


Mime
View raw message