Hi Gilles, > > Although it is nice to work on a new design, I now have a problem with the > issue as a whole: Where are the people (and applications) that need this? > At least four persons made suggestions/comments on what was maybe wrong or > could be improved, but they either are not active developers, or are not > even posting to the ML anymore. > Fair enough. I guess the amount of interest raised by this thread will reveal how "urgent" this issue actually is...
> > Thus we lack the potential "real-life" use-cases (plural) that should guide > the refactoring. > Certainly, some rationalizing can be performed for its own sake (like some of > your proposals below) but a thorough redesign runs the risk of being not > vastly better that what we current have. It's not the problem that we could > be wrong (that's allowed, I think ;-), and we'll just re-redesign later on), > but it's an issue of priority. > > Is it wise to spend time working on something that nobody really needs > (judging from the number of comments which your otherwise valuable review > work has brought to this ML)? > > Thus... > Point taken! > >> >> My first suggestion would be on the visitor design pattern vs. >> map(UnivariateFunction). The former is specified in the RealMatrix >> interface, the latter is specified in the RealVector abstract class. I >> think both concepts are similar, and both are useful: >> - visitors know about the cell they are visiting, >> - map() doesn't. >> Maybe it would be nice as a first step to unify these concepts. Two >> options there >> 1. Specify both in both interfaces, >> 2. Specify only the visitor design pattern, and create a factory which >> would return a visitor from a UnivariateFunction (ignoring the indices >> of the current cell). > > ... this is a well-defined (limited in scope) rationalization. > [And I'd vote for option 2.] > But ... > I can start a new thread/JIRA ticket on this particular issue. > >> A second step could then be to remove most of the norm calculations >> from the matrix and vector interfaces, and implement these >> functionalities as visitors. >> >> Other major issues are >> - tagging interfaces/marker methods to dispatch the objects to the >> most optimized algorithm (e.g. multiplication of sparse, symmetric, >> and so on matrices). See >> http://markmail.org/thread/vkwe5x2jtozcjkge >> http://markmail.org/thread/j4xjdtchpw33xpgr >> - implementation of "views" of a matrix/vector. IIRC, Ted suggested >> such a feature a while ago. This would be a very useful feature (just >> like a[3:5] in matlab, octave, python and the likes). This I think >> would also be a very useful addition. > > ... this seems just "nice" (i.e. not justified by the advertised uses of > CM). > While I agree with you on the tagging interfaces/marker methods issue, I think that views would really be a useful addition. There must be a reason why the ":" operator is implemented in matlab, python + scipy + numpy, R, octave, and so on... I can provide you with a particular use case I'm meeting constantly those days. > > Unless those people who, some time ago, expressed a willingness to > contribute to the matrix interfaces come back, I'd much prefer to devote > some time to get "BOBYQAOptimizer" in a better shape (Java-wise).[1] By > the way, since there are many computations there that deal with matrices, > it could also give some clues as to what is missing in the CM matrix > functionality in order to improve another part of CM. > Unfortunately, I'll be pretty useless on this issue, as my background in advanced numerical optimization is pretty thin... To sum up: if this thread does not raise a major discussion, maybe we will stick with tiny API changes. I do think that RealMatrix and RealVector should be as similar as possible, and would like to improve the APIs in this direction. It was never my intention to rewrite the whole thing anyway. What would you think of this reduced scope? Sébastien --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
