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
