Hello. > as agreed, I've started a JIRA ticket on this long-standing issue (see > MATH-765). This ticket is really meant as a summary of the discussions > which should take place on the mailing list, so please refrain from > adding comments (unless absolutely necessary). Children tickets will > be linked to this parent ticket once we agree on concrete tasks. > > At the moment, there is nothing really fancy on this ticket. I merely > compared the interfaces of RealMatrix and RealVector, and drew a few > conclusions. I would be interested by your feed-back on the comments > I've made.
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. 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... > > 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 ... > 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). > These are just a few thoughts, I'm curious to read what everyone > thinks. Thanks beforehand for your feedback! 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. Best, Gilles [1] In its current state, it fails many basic goals of CM: robustness, efficiency, programming style, code clarity, etc. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
